Chris's Wiki :: blog/sysadmin/LittleScriptsVIII

A little script: `nssh`

December 20, 2011

(Once again it's been a while since the last little script.)

One of the things that we do reasonably often around here is install and reinstall servers. When we do this, the server's SSH host key changes (either permanently or temporarily until we can restore its canonical key), and of course then ssh'ing in to the newly reinstalled server complains about host key mismatches.

A while back I got tired of having to deal with this by hand, so I decided to automate it. Enter a script that I call nssh:

#!/bin/sh
# ssh with no host keys
exec ssh -o 'UserKnownHosts File /dev/null' \
         -o 'PubkeyAuthentication no' \
         -o 'StrictHostKeyChecking no' "$@"

(Okay, my script actually doesn't explicitly set StrictHostKeyChecking because I long ago made it a default in my .ssh/config, on the grounds that this was what I was doing by hand anyways; I always just said 'yes' when ssh prompted me. I have a number of odd behaviors with ssh.)

This is a trivial little script but it's turned out to be very handy, like others before it. Tiny or not, it eliminates an irritating bit of make-work and that makes me happy.

(The need for this script while dealing with machines being reinstalled is an artifact of how our install system works. A more sophisticated install system could arrange for the correct canonical host keys to be installed before you needed to ssh to the new machine.)

Comments on this page:

From 71.179.165.244 at 2011-12-20 10:51:41:

A warning about 'StrictHostKeyChecking no' by default. I had the same thought as you did, and tested the behavior. When set to 'no', ssh will connect anyway if the host key changes and you're using public key auth (it will print a warning, and disable password based auth however), which doesn't prevent a man in the middle attack if the person has access to your public key (which it's very likely they will have).

From what I can tell, there is no way to have ssh automatically 'Trust on first use' - assume you answer 'yes' to the initial query, but then refuse to connect if the host key ever changes. It's a shame, as this would be ideal behavior for automated scripts that use ssh.

Mark

By cks at 2011-12-20 13:37:33:

Your comment made me curious so I went digging. The short version is that as far as I can tell, public key auth blocks effective man in the middle attacks; if there is a MitM, your public key will fail to authenticate. The full explanation is long and complicated enough to be an entry, SshAndMitM.

(You can impersonate a server even without knowing my public key at all; you just accept whatever signature I claim as valid. But the tricky bit is getting me authenticated to the real server while you sit in the middle, reading the conversation.)

Written on 20 December 2011.

«	An advance fee fraud spam aphorism

SSH, man in the middle attacks, and public key authentication

A little script: nssh

Comments on this page:

A little script: `nssh`