|
This is the BSDA Study Guide Book written via a
wiki collaboration.
This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/Preserve_existing_SSH_host_keys_during_a_system_upgrade.html.
Preserve existing SSH host keys during a system upgrade
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*
|