[RndTbl] ssh host checking

[Trevor Cordes]

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 at 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.