## Preserve existing SSH host keys during a system upgrade ##

[Author](authors.html): [[KevinDKinsey]]

[Reviewer](technical_reviewers.html): _name_ _[[contact]]_ _[[BSD_flavour]]_

[Reviewer](technical_reviewers.html): _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 ###

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 ###

`/etc/ssh/ssh_host*_key*`