insecssh
Yes, You Should Not discard cached ssh host keys without looking. An unexpected change of an ssh host key is always a reason to step back from the keyboard and think. However, there are situations when you know that a systems' ssh host key has changed, for example when the system reachable under this host name has been redeployed, which happens increasingly often proportionally to the devopsness of your environment, or for example in test environments.
Later versions of ssh offer you the ssh-keygen -R command line to paste from the error message, so that you can abort the connection attempt, paste the command and reconnect again. This will still ask for confirmation of the new host key though.
Almost every sysadmin has an alias or wrapper to make handling of this situation easier. Solutions range from using "StrictHostKeyChecking no" and/or "UserKnownHostsFile /dev/null", turning off this layer of securit altogether either globally or usually too broadly, to more-or-less sophisticated solutions that involve turning off know-host file hashing, parsing client output and/or grep-sed-awk magic. grml even comes with an insecssh script that is rather neat and that I used until I developed my own.
Later ssh versions (not including the 6.7 in Debian jessie, but the 7.4 in debian sid) do offer a -G command line option which will give access to configuration options after the complete client configurtion was processed. This will allow you to neatly get access to the actual hostname the ssh client will connect to. This can, in turn be used to obtain the IP address so that all traces of the host and its IP addresses can be removed from the known_hosts file before the actual connection is done.
The following script is the insecssh that I currently use. It only uses documented interfaces to the ssh client which I consider rather neat.
#!/bin/bash
HOSTNAME=$(ssh -G "$@" | grep '^hostname ' | awk '{print $2}')
CNAME="1"
while [ -n "$CNAME" ]; do
CNAME=$(dig +short +search -t CNAME "$HOSTNAME")
if [ -n "$CNAME" ]; then
HOSTNAME="$CNAME"
fi
done
IP4ADDRESS=$(dig +short +search -t A "$HOSTNAME")
IP6ADDRESS=$(dig +short +search -t AAAA "$HOSTNAME")
echo "HOSTNAME $HOSTNAME"
echo "IP4ADDRESS $IP4ADDRESS"
echo "IP6ADDRESS $IP6ADDRESS"
[ -n "$HOSTNAME" ] && ssh-keygen -R "$HOSTNAME"
[ -n "$IP4ADDRESS" ] && ssh-keygen -R "$IP4ADDRESS"
[ -n "$IP6ADDRESS" ] && ssh-keygen -R "$IP6ADDRESS"
ssh -oStrictHostKeyChecking=no -oVisualHostKey=yes "$@"
Ugliness results from the necessity of following CNAMEs manually since there is - to my knowlegde (educate me!) - no command line utility that has the output simplicity and selection powers of dig which can automatically follow CNAMEs without relying on the recursor having the CNAME cached or not.
Use this script if you know that a host has changed its host key. It will first zap all knowledge of the previous host key from known_hosts and then invoke the ssh client with the given arguments from its command line, with options added so that you'll see the new host key in random art and that you don't need to manually confirm the new host key.
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded