IoT Engineering Tip: Simplifying SSH Host ECDSA Key Checking

If you keep wiping and re-installing the operating system on IoT devices such as Raspberry Pis, SSH will get cranky because the board's public key will change

encryption goo.gl yiaw4a

Those of you new to Internet of Things (IoT) engineering and using boards such as the Raspberry Pi will probably have come across an irritation: Every time you wipe the operating system on your IoT device and then try to use the Secure Shell (SSH) to access it, SSH will complain with something along the lines of:

RedQueen:~ mgibbs$ ssh pi@192.168.0.37

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@    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 ECDSA key sent by the remote host is

SHA256:X0L/BQW/2WvWKnkIAsRGcSr41Hsw/uVffWkP7bLFUuo.

Please contact your system administrator.

Add correct host key in /Users/mgibbs/.ssh/known_hosts to get rid of this message.

Offending ECDSA key in /Users/mgibbs/.ssh/known_hosts:12

ECDSA host key for 192.168.0.37 has changed and you have requested strict checking.

Host key verification failed.

RedQueen:~ mgibbs$ 

My machine is  is named RedQueen (I use an "Alice's Adventures in Wonderland" scheme for naming devices on my network) and I'm SSHing to a Raspberry Pi running Debian "Jesse" via NOOBS so the standard login is user name "pi" with password "raspberry".

The problem here is that entry 12 in my known_hosts file states that the Elliptic Curve Digital Signature Algorithm (ECDSA) fingerprint from the host I just connected to is not the same as the host fingerprint previously recorded for that host (which it isn't because every installation of Linux gets a new ECDSA public key). The warning line is:

Offending ECDSA key in /Users/mgibbs/.ssh/known_hosts:12

You could edit your known_hosts file (usually found at ~/.ssh/known_hosts) and delete only the offending line which, for my example above, looks like:

192.168.0.37 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNT$

This will work fine because by removing the specific line for that host you won’t change the ECDSA signature checking for other hosts, something that is highly advisable if there’s any possibility of bad guys getting involved. A quick way to do this is to use the sed editor like this:

sed -i 12d ~/.ssh/known_hosts

Now when you retry SSHing to that host, a new entry will be created  in known_hosts when you complete the dialog:

RedQueen:~ mgibbs$ ssh pi@192.168.0.37

The authenticity of host '192.168.0.37 (192.168.0.37)' can't be established.

ECDSA key fingerprint is SHA256:X0L/BQW/2WvWKnkIAsRGcSr41Hsw/uVffWkP7bLFUuo.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '192.168.0.37' (ECDSA) to the list of known hosts.

pi@192.168.0.37's password: 

 

The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

 

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Sat Aug 20 19:14:09 2016 from 192.168.0.180

pi@raspberrypi:~ $ 

But having to edit known_hosts for each and every changed host will quickly become a pain even when it’s as simple as using the sed command. A better choice is to disable Strict Host Key Checking which you do by editing the SSH configuration in ~/.ssh/config (if the file doesn’t exist, then you simply create it). Note that this is the config file for the current user; for system-wide SSH configuration it’s /etc/ssh/ssh_config). Here’s what you’ll need in the configuration file:

Host [IP Address] 

   StrictHostKeyChecking no

   UserKnownHostsFile=/dev/null

If you use a wildcard specification for [IP Address], for example 192.168.0.*, then strict checking will still apply to every host that doesn't match that specification. The assignment of UserKnownHostsFile to /dev/null causes the list of entries that would normally come from known_hosts to come from the null device (which returns nothing) so as there won’t be an entry for the host, SSH will ask whether it's okay to continue and when you answer “yes” it’ll simply connect:

RedQueen:~ mgibbs$ ssh pi@192.168.0.37

Warning: Permanently added '192.168.0.37' (ECDSA) to the list of known hosts.

pi@192.168.0.37's password: 

 

The programs included with the Debian GNU/Linux system are free software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

 

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Sat Aug 20 19:35:18 2016 from 192.168.0.180

pi@raspberrypi:~ $ 

Done and done. Your life will be just that little bit easier now.

So, what IoT problems are you wrestling with? Comments? Thoughts? Connect to me or comment below then follow me on Twitter and Facebook.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Must read: Hidden Cause of Slow Internet and how to fix it
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.