Preserve existing SSH host keys during a system upgrade
Reviewer: name contact BSD flavour
Reviewer: name contact BSD flavour
Concept
In addition to knowing how to generate a system's SSH keys, know:
- where host keys are located, and
- how to preserve them if the system is upgraded or replaced.
Introduction
When sshd(8)
is first run, a passwordless public/private key pair is generated on the host to assist clients in identification of the host. When a client first connects to sshd
, the server's public key fingerprint is stored on the client's machine in ~/.ssh/known_hosts
; on subsequent attempts, the given fingerprint is compared with the stored key fingerprint in the same file. If the fingerprints do not match, ssh(1)
asks for confirmation, warning you of potential "man in the middle" or similar attacks (in other words, if ssh
complains about the server key but you've not changed it, be very careful what you do next!)
This behavior can lead to difficulties if a machine is upgraded or replaced and the "original" server keys are not preserved; namely, clients may be unable or unwilling to connect to your server; at least, the phone will ring frequently until everyone has been assured that your server is trustworthy (or they quit using your server and become someone else's customer ).
Don't Lose Your Keys!
SSH Server host keys live under /etc/ssh
:
""[root@myhost][/etc/ssh] ""# ls -l *key* -rw------- 1 root wheel 668 Aug 9 2005 ssh_host_dsa_key -rw-r--r-- 1 root wheel 618 Aug 9 2005 ssh_host_dsa_key.pub -rw------- 1 root wheel 543 Aug 9 2005 ssh_host_key -rw-r--r-- 1 root wheel 347 Aug 9 2005 ssh_host_key.pub -rw------- 1 root wheel 887 Aug 9 2005 ssh_host_rsa_key -rw-r--r-- 1 root wheel 238 Aug 9 2005 ssh_host_rsa_key.pub
Six files, three key pairs, for RSA1, RSA2, and DSA. It may be a good idea to output the above information to a file so you can verify permissions after the upgrade or system replacement.
Examples
Store a listing of the keyfiles in your $HOME directory in the file "key_list":
""# ls -l /etc/ssh/*key* > ~/key_list
Create a directory in $HOME, and, (if successful) copy the server's key files to it, preserving (-p
) file modification times, modes, ownership, etc.:
""# mkdir ~/serverkeys && cp -p /etc/ssh/*key* ~/serverkeys/
After the upgrade or replacement (make sure and save your $HOME directory!!), copy the keys back to /etc/ssh
:
"" # cp -p ~/serverkeys/*key* /etc/ssh
Then you can test to see if you messed things up with the wrong umask (permissions). You might try this little trick with diff(1)
- (using "-" as a file argument to diff
means "read from standard input"):
""# ls -l /etc/ssh/*key* | diff - ~/key_list
If diff
produces no output, you're finished. You've copied and restored your server keys successfully. (Note: sshd
won't start if the owner or permissions are wrong on the key files, so this step is pretty important ;-)
Practice Exercises
- Examine the examples above carefully and make sure you understand what they are accomplishing, then try the procedure on your own server.
More information
/etc/ssh/ssh_host*_key*