Front | Info | Lists | Newsfeeds | Study Guide | What is BSD?
Advertisement: The OpenBSD PF Packet Filter Book: PF for NetBSD, FreeBSD, DragonFly and OpenBSD

BSD Links
·New Links
·User Groups

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

Preserve existing SSH host keys during a system upgrade


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.


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:

# 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
    -rw-------  1 root  wheel  543 Aug  9  2005 ssh_host_key
    -rw-r--r--  1 root  wheel  347 Aug  9  2005
    -rw-------  1 root  wheel  887 Aug  9  2005 ssh_host_rsa_key
    -rw-r--r--  1 root  wheel  238 Aug  9  2005

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.


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

  1. Examine the examples above carefully and make sure you understand what they are accomplishing, then try the procedure on your own server.

More information


Front | Information | Lists | Newsfeeds