Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Key Handling
Public-key cryptography is used in two places: server identification and two-factor authentication. This means that there are keys to be managed, protected, transported, and eventually destroyed. Key handling is the largest obstacle to the wide-scale deployment of OpenSSH. Because OpenSSH was designed as a point-to-point solution with no public-key infrastructure in place, all key operations must be done manually. This is not a problem for small deployments; however, the problem does not scale.
Because they are the foundation for systems security, keys must be handled with care. If private keys are divulged, security is compromised because the system appears to be secure when, in fact, it is not.
Host Keys
Server identification is accomplished by a host key pair. The openssh.server init script, which you can find on the Sun BluePrints website, generates a key set if it cannot find a host key. This key set is used to identify the server to the client. The private key remains private to ensure the integrity of the system. The client downloads the public key and compares it to its copy in known_hosts. If the key is different than it is expected to be, a warning message is printed and the connection is refused. The following is an example of this warning.
$ /opt/OBSDssh/bin/ssh some_host @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is c3:6f:30:ff:84:e1:e0:d6:ef:28:e7:76:f2:49:ea:be. Please contact your system administrator. Add correct host key in /export/home/user/.ssh/known_hosts to get rid of this message. Offending key in /export/home/user/.ssh/known_hosts:2 RSA host key for some_host has changed and you have requested strict checking. $ |
The problem is how to get the public host key to the client in the first place. Another problem is what to do when the public host key has been regenerated due to loss, server upgrade, or compromise. Having multiple users call support because of the preceding warning message could create quite a support headache. Further, having users change keys manually would be even less desirable.
The client configuration option StrictHostKeyChecking controls how the client reacts to new hosts keys. If you set this option to yes, OpenSSH will not make connections to unknown servers. If you set the option to ask, OpenSSH will prompt users to accept a new host key if the server is unknown. If you set the option to no, OpenSSH will add new host keys without prompting users. The no option setting will allow connections to servers with modified host keys.
The easiest solution is to simply disable StrictHostKeyChecking by setting it to no. Blindly accepting new keys allows man-in-the-middle attacks and is not recommended. If your users can be trusted to act responsibly, then set the option to ask. Users can manually verify the host key by comparing the value in known_hosts to the value ssh_host_key.pub, ssh_host_dsa_key.pub, or ssh_host_rsa_key.pub depending on the protocol and public cryptographic system used to connect. If the values don't match, something odd has happened. This could be caused by an active attack or possibly just a server reinstallation. Respond according to your local policy.
Another solution is distribute a known_hosts file to users; however, it is difficult to do this in a secure fashion. You must decide how to securely collect public host keys and how to securely distribute the file to the users. Again, there are problems of scalability with any solution. Fortunately, changes to host keys should be infrequent.
The most secure method of gathering keys is to log in to every server and manually copy the public host key to a portable medium such as a floppy disk, CD-RW, or smartcard. For sites with a large number of machines, or during the first deployment of OpenSSH, this burden is significant. Alternatively, you can configure a client with StrictHostKeyChecking set to no, access every single host, copy the public host key, exit, and then compare the key with the value in known_hosts. Display a warning message for any server with a differing key. This can be automated using Korn shell, PERL, or some other scripting language.
Ssh-keyscan can also be used to generate a list of host keys. The risk is getting the host key of a compromised machine. None of the solutions are perfect. There are some serious tradeoffs between convience and security. At the minimum, set StrictHostKeyChecking to ask and train your users to check the host keys.
A novel use of ssh-keyscan is to regularly check for altered keys. At routine intervals, probe the servers and check if keys have been altered. This can provide warning of an intrusion or a non-logged installation.
With public host keys gathered, you must decide how to securely distribute the file to users. An easy solution is to integrate the file into the deployment packaging such as the OBSDssh package. The file can be placed on an ftp or http server. Also distribute a preferably signed hash (MD5 or SHA-1) of the file so the user can verify the integrity of the file. (OpenSSL has the capability of performing the hashes.)
For sites with a public-key infrastructure, a pretty good privacy installation, or a Gnu privacy-guard installation, distribute the file and its hash cryptographically signed.
With the hassle of users seeing an unfamiliar warning about a changed host key, there is the temptation to archive the public and private host key pairs onto a system. The key pairs would be replaced after a system was reinstalled or replaced. This is risky and not recommended. Any system storing the keys would be a tempting target and if it was comprised all keys within it would also be compromised. It is better to deal with the occasional host key change through user education and notices of reinstallation. If it is necessary to archive keys, store them offline, in encrypted format, and in secure storage such as a safe.
In the event of a server compromise, destroy host keys. An attacker with knowledge of the private portion of a host key could impersonate the host and perform a man-in-the-middle attack.