Go Premium for a chance to win a PS4. Enter to Win


can I auto-update known hosts info?

Posted on 2014-03-17
Medium Priority
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
  • 5
  • 3

Assisted Solution

PNutButterAdmin earned 1000 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 31

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?
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.


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 31

Accepted Solution

serialband earned 1000 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
HostName example.dyndns.org
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 31

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

Ask an Anonymous Question!

Don't feel intimidated by what you don't know. Ask your question anonymously. It's easy! Learn more and upgrade.

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…
It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.
Suggested Courses
Course of the Month10 days, 18 hours left to enroll

886 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