On 2010-09-10 Sean Walberg wrote:
Hey Trevor,
If you're connecting with a password to a compromised box or otherwise being hit with an MITM attack, you'll give up your password. If you're connecting to the same server with a key, you won't compromise your key because the private key isn't sent over the channel. It's only used to decrypt a challenge encrypted by the public key.
Thanks for the response, sorry for my delay I haven't had time to deal with this again until now.
I'm using rsa & dsa keys to login. No passwords.
In both cases, the data channel will also be visible to the attacker.
Oops, that would be bad.
The .ssh/known hosts file will work on hostnames, so I'm not sure why a change in IP is flagging the host key checks because the key shouldn't change.
Hmm, my known hosts file is almost all IP's (no hostnames) even though I'm pretty sure I'm connecting with hostnames. The DNS is all dynamic DNS so the hostname->IP mapping changes a lot (for DSL anyhow).
Maybe I'll look into getting ssh to use hostnames, not IPs, in knownhosts. Unless, perhaps it is using IPs when it is finding duplicate hostname/IP tuples.
Your thought about the key was my thought exactly. I'm not sure why it even needs the tuple at all. Why not just store the key and say "this key is good no matter the IP/hostname".
One alternative that might be a good middle ground would be to run with both parameters set to "yes". If an event happens, the ssh will fail. You could then run some checks to make sure things are OK
Not good for my automated script. It's mission-critical and I would be bugged several times a day probably (I hate MTS DSL...) with failures. I really need to FaF.
($old_ip != $new_ip) and then do a token "ssh $hostname -o StrictHostKeyChecking=no -o CheckHostIP=no /bin/false " which would be enough to save the key on your management station. Re-try the ssh with full security. Log the event somewhere.
Hmm, perhaps using expect or something to automatically interface with ssh and check the fingerprint when things fail might be a solution. You've given me some good ideas.
I did something similar in the EC2 environment, but I could guarantee the IP address was new so there might be some tweaking needed if you stomp on a previously known IP.
Perhaps I could make a script to associate dates with IPs and delete any old ones, or any where it can determine the IP was the last one used by a certain host.
There also might be options outside of SSH but that would depend on what you're trying to do.
Sounds like the only options will be outside of ssh :-( Not ideal, but certainly doable.
On Fri, Sep 10, 2010 at 3:09 AM, Trevor Cordes trevor@tecnopolis.ca wrote:
What security will I lose by using ssh with: -o StrictHostKeyChecking=no -o CheckHostIP=no ?
I have a script that connects automatically to dozens of linux boxen (that I control) on the internet using dsa/rsa keys. Many of these are on MTS DSL and so change their IP's frequently (often many times a week). They all have dynamic dns setup so I can always access them via a DNS domain name (rather than IP).
If I use the ssh defaults of StrictHostKeyChecking=ask and CheckHostIP=yes, it mostly works as expected, but sometimes my script will hang with ssh waiting for tty input with the usual:
The authenticity of host 'foo.com (141.162.215.81)' can't be established. Are you sure you want to continue connecting (yes/no)?
I don't mind this for new boxes where I haven't confirmed the fingerprint yet, but for existing boxes where the IP has changed, it sometimes gives me grief. I can't recall all the particular instances, but the one that just hit me was one of my MTS boxes cycled onto an IP that was previously used by a different box! Seems rather unlikely, but with DSL hanging up all the time, it's bound to happen. I see no way around this occurrence except to use the above -o options to disable all checks.
So what attacks am I really opening myseful up to with those settings? Is the worst case that a MitM captures my commands? Or is the worst case that they gain my password/key and access to the remote system?
What else?
It sure would be nice if I could, on my local box, install a key or something from each of the remote boxen and say that I never care about what IP it has at the moment, just check the key and be happy & secure.
For all scenarios assume local + remote boxes have not been compromised.