can I auto-update known hosts info?

Posted on 2014-03-17
Last Modified: 2014-03-19
I pick up files from a remote server using sftp. This connection and retrieval are done automatically via a cron script using sftp -b. Every so often the remote host changes its RSA host key and the connection attempt returns the message shown below. When this happens I have to manually go into the .ssh/known_hosts file, delete the entry for that host, manually sftp to the host, and answer "yes" to the "Are you sure you want to continue connecting" message.

Is there a way to automatically update the known_hosts file so I don't have to manually intervene and the cron job can continue without aborting?

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/ohprs/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/ohprs/.ssh/known_hosts:9

Open in new window

Question by:jmarkfoley
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 3

Assisted Solution

PNutButterAdmin earned 250 total points
ID: 39934598
There are a variety of ways that you can get around this. How concerned are you of actually experiencing an attack such as that one listed in the warning?

If you believe that it is unlikely for this to be a security concern, then you could try a trick that I use for ssh:ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no Pnut@
LVL 30

Expert Comment

ID: 39935906
That's an unsafe and horrible work around.  Why bother with secure shell at all?  Just use rsh then. :P  You really should learn about the keys and fingerprints to be sure the system isn't really a man in the middle attack.

I normally publish my host keys and fingerprints for my users, so you should check if your admin has that posted somewhere for you to verify.  If it's not available, and if you trust the site, then first copy your known_hosts file then remove line 9.  You will be prompted for a knew fingerprint.

You should be using ssh keys so that even if that is a man in the middle attack, you won't be compromising your password.  Your key will just fail and you'd know if it was fake.  If you only use passwords, then you can't easily verify if it was a man in the middle attack or if the admin had reinstalled the system and created a new host key.  If your admin reinstalled it and kept your home folders or use ldap or AD, you will be able to connect with your ssh key automatically even if the host key has changed.  You can't do that with a password.

Author Comment

ID: 39936001
Hmmm, interesting, but I don't think I want to bypass the use of the known_hosts file totally. I suppose I could have the sftp script watch for that WARNING, and retry with the -o StrictHostKeyChecking=no, option. If you use that option, why is the -o UserKnownHostsFile=/dev/null, necessary?
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.


Author Comment

ID: 39936045
serialband: I am the administrator. The host in question is not in our domain. It is the host of a health insurance claims service provider. We are not using passwords, just the public key. Currently I am doing exactly as you prescribe: editing the known hosts file, removing the old host key, manually connecting to their site and answering "yes" to the "Are you sure you want to continue connecting" message.

Unfortunately, when this happens we miss the file transfer for that session. Also, I have to be monitoring transfer results because I don't get notified of the failure (well, I do now. I just added that notification to the script). What I was looking for was an automated way of do this procedure. What prompted this notion was a message I received from the remote host's admin:

"Hi Mark, The back-end server behind the ST3 alias updated last night.  It looks like your script doesn't trust hosts dynamically."

The word "dynamically" in his message led me to believe there was some such way of doing this.

If there is not a way to do this (i.e. this fellow knows not of which he speaks), PNutButterAdmin's solution might be a good band-aid. I could have the script notify me when it gets this WARNING, then have it retry the connection with the  -o StrictHostKeyChecking=no, option. That will permit the file to be picked up, and prompt me to later go in and manually modify the known_hosts file. This is an outgoing connection only. The remote does not connect to my server and has not password or key to do so.
LVL 30

Accepted Solution

serialband earned 250 total points
ID: 39938006
You're not the sysadmin of the foreign box that you're logging into.  You should ask him what he means by "dynamically."  It seems that if his host is constantly changing, you can't verify the validity of the remote host with the known hosts file.  He's basically introducing an insecurity to the use of ssh.  He should have a known host public key posted somewhere that you can grab and copy/update to your own know hosts file and you should be good to go.

If he means that his IP address is changing, you can just set your ssh client to only trust just the host key, rather than both host key & IP.

Add these to your ~/.ssh/config
Host nickname
CheckHostIP no

If he means that you should blindly trust and accept random ssh host keys, then he's an idiot admin.  He should have copied the previous server's host keys to the new one in place, or publish the public key for you to update.  That's the proper way to check your keys with a script.  If you're maintaining some kind of high availability ssh service, you should either post the keys or not change them.  If you haven't been verifying the keys, then, securitywise, you're doing it wrong.

That work around by PNutButterAdmin destroys all security benefits of ssh.  Why bother with ssh if you're going to do that, since FTP or rsh would work.  That's what my first paragraph in my previous post refers to.  The 2nd paragraph refers to the other admin, of the remote server you're connecting to, that told you that "your script doesn't trust hosts dynamically," and I really don't know what he means by that without some more information.

Author Comment

ID: 39939738
OK, I'll email the remote sysadmin and find out what they're doing. I'll post back.

Author Comment

ID: 39940488
Well, the answer it that they expect the client to look at the IP and if the IP is the same the known_host the client will automatically trust it. I pointed out that this kind of defeats the purpose of having the host key since IPs can be faked. He said "I'm not saying that's right or wrong, but that's how other clients do it."

What do you think about that?
LVL 30

Expert Comment

ID: 39940554
<Rolls Eyes>  It means, he either doesn't understand or doesn't care about security at all and that he's only using ssh because someone told him it was "secure".  At least you're not using a password.  I would tell him that it's wrong, even if the other clients were doing it.

If I were in your shoes, I'd ask him to post the host keys somewhere safe to download and verify or ask him to copy the old host keys to the new box to maintain security.  Neither of those require too much effort on his part.  If he's also allowing password access, I'd also tell him that he's compromising the security of the system.

Author Comment

ID: 39940639
I don't think this fellow is the sysadmin in charge of the configuration, but I will pass this info on to him in the hopes that he'll share it with the responsible parties. I agree with you that they are creating an insecurity in their system that "someone" should address.

Featured Post

Back Up Your Microsoft Windows Server®

Back up all your Microsoft Windows Server – on-premises, in remote locations, in private and hybrid clouds. Your entire Windows Server will be backed up in one easy step with patented, block-level disk imaging. We achieve RTOs (recovery time objectives) as low as 15 seconds.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

If you have a server on collocation with the super-fast CPU, that doesn't mean that you get it running at full power. Here is a preamble. When doing inventory of Linux servers, that I'm administering, I've found that some of them are running on l…
Join Greg Farro and Ethan Banks from Packet Pushers ( and Greg Ross from Paessler ( for a discussion about smart network …
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…
Suggested Courses

630 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question