Re: SSH key

For the users' convenience, you might want to copy the old host keys to a safe place, and copy them back once the update is complete.

In case you're unfamiliar with "host keys", let me explain in more detail:-----SSH uses two kinds of keys. Both have similar structure, but their purposes are very different.

1.) User authentication keys:

These are usually stored in the .ssh subdirectory of the user's home directory. If you use SSH authetication when connecting from one system to another, the private part of the key must be available to the SSH client at the starting system, and the public part of the key must be copied to the appropriate location on the destination system.

In general, the system administrator does not need to do anything special with these keys, even when there is an OS upgrade. If the users' home directories are not overwritten in the upgrade (or are restored from backup after the upgrade is completed), these keys will work after the upgrade just as before.

2.) Host keys (host identity verification keys):

These are usually managed automatically by the SSH software, and sometimes the users aren't even aware of them. The host key is generated on the server side, usually when the sshd daemon is installed for the first time. With the host key, the private key is in the server and the public key is in the client(s). The key files are located in the SSH configuration directory (/opt/ssh/etc for HP Secure Shell).

When the SSH client connects to a system it has not seen before, it receives the server's public key and usually requires the user to confirm the connection. When the same server is connected again later, the client will use the public key it already has to confirm that the server is the same as before, to prevent Man-in-the-middle type attacks. If the host key of a previously-known server has changed, most SSH clients will display a scary message with a lot of exclamation marks: "Warning! The host key has been changed! This might indicate a serious security problem!"

When a server is upgraded, the scary messages can be avoided if the sysadmin keeps the old host keys safe and copies them back to the server after the upgrade. The permissions of the key files are important, as always with SSH.

If the /opt/ssh/etc/ssh_known_hosts file has non-zero size, it might be useful to preserve it too.

Example for HP SSH:(Assumption: sysadmin@another-server.example is an user account on another host, where the sysadmin can at least temporarily store things.)

Re: SSH key

If your users' home directories are on NFS or you're going to restore the home directories from backup after the upgrade, the other keys will be restored as a side effect of that.

But if the system is going to be used for a new task after the upgrade, starting over with a minimal /home and no authentication keys configured might be a smart thing to do. It certainly ensures that someone whose access should have been blocked long ago but wasn't (because of some human mistake) will no longer be able to use an old SSH key to get in.

An important exception might be the authorized keys for the root account - but as a sysadmin, you should already know if such keys exist, and their exact purpose.

If you find any keys for root access you don't know about, at any time, in any systems you're held responsible for, you should immediately disable or remove them, until someone can explain why the keys should be there (and that explanation had better be a good one!)