Solved

can I auto-update known hosts info?

Posted on 2014-03-17
9
547 Views
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?

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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
74:7c:8d:2b:d9:61:7a:52:03:70:e4:c6:5a:4a:81:4c.
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

0
Comment
Question by:jmarkfoley
  • 5
  • 3
9 Comments
 

Assisted Solution

by:PNutButterAdmin
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@10.101.10.100
0
 
LVL 27

Expert Comment

by:serialband
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.
0
 
LVL 1

Author Comment

by:jmarkfoley
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?
0
 
LVL 1

Author Comment

by:jmarkfoley
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.
0
Get up to 2TB FREE CLOUD per backup license!

An exclusive Black Friday offer just for Expert Exchange audience! Buy any of our top-rated backup solutions & get up to 2TB free cloud per system! Perform local & cloud backup in the same step, and restore instantly—anytime, anywhere. Grab this deal now before it disappears!

 
LVL 27

Accepted Solution

by:
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
HostName example.dyndns.org
CheckHostIP no

http://askubuntu.com/questions/48317/trust-ssh-server-based-on-key-instead-of-if-keyip-match


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.
0
 
LVL 1

Author Comment

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

Author Comment

by:jmarkfoley
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?
0
 
LVL 27

Expert Comment

by:serialband
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.
0
 
LVL 1

Author Comment

by:jmarkfoley
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.
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

I. Introduction There's an interesting discussion going on now in an Experts Exchange Group — Attachments with no extension (http://www.experts-exchange.com/discussions/210281/Attachments-with-no-extension.html). This reminded me of questions tha…
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é.
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

746 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

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now