OpenSSH and SSH Known Hosts

In this blog we look at the SSH Known Hosts process and how we can centralise it on CentOS 7. Using SSH is a common method in Linux to remotely connect to your servers or desktops and is secured though dual key encryption remotely. The data will always be encrypted as will authentication.   We can also add levels of host authentication into the mix so we can be sure that we are connecting to the host we think we are or “known_hosts” or SSH Known Hosts. Here we expand the known_hosts mechanism and expand to create a centralize your known_hosts file on CentOS 7

The Server’s Public Key.

The default behavior of the SSH client on most Linux distributions is to ask if you want to accept the Servers’s public key when you connect to a server that you do not already have their key in your store. If you accept the client will store the Server’s public key in the client’s personal keystore, ~/.ssh/known_hosts. The remote server then becomes known adding the the SSH Known Hosts of that user.  Subsequent times that the user connects to this Server, as they already have its key, the user will not be prompted to store the key. The security behind this also mean if the user connects at a later date and the remote server shows another Public Key then connection is refused as the key is not trusted for that server.

Risks with the Default Settings

As with most things the default setting provide a mechanism of ease of use balanced with security. As a process becomes more convenient to use, often it becomes less secure. If we connect to a host for the first time and we have not validated that it is actually the server we think that it is we may store an incorrect public key on the store. We see the similar behavior in web-browsers where one connects to unknown or untrusted web-site warnings will show about the server’s certificate. This is the same thing but we are allowing the user to make the choice which in a secure environment may not be the best choice.

We can change the client so that it may only to connect to Servers that are already known or, in other words : Servers that are already SSH Known Hosts and their Public Key is stored in the client and trusted. The configuration can be set as the default for all clients in the following file:

/etc/ssh/ssh_config

StrictHostKeyChecking is the setting we need too look for:

StrictHostKeyChecking Yes #Only connect when the key is pre shared - most secure
StrictHostKeyChecking Ask #If the key is not already stored ask to store. If it is stored check the key is the same - Default and less secure
StrictHostKeyChecking No #Store the key if required in the SSH Know Hosts file but don't worry if it matches - Insecure

Populating the Key-Store

We can populate the key-store manually by copying the Server’s Public Key to our client or more easily via the ssh-keyscan command. The command although convenient also carries the risk that we may connect to a malicious server during the scan and again store the incorrect key. For ease, I demonstrate this method in the video. However, if you have may users connecting from the client it would be painful to add the public key to each users  ~/.ssh/known_hosts file. To centralize this I would suggest that in a secure environment that you use the common SSH know hosts file or key-store which is:

/etc/ssh/ssh_known_hosts

This then can act as the key-store for all users on the client and is much simpler to manage and, of course, more secure.

In Conclusion

SSH provides a secure encryption mechanism to maintain data security across the network, implement StrictHostKeyChecking on the client will also allow for Host Authentication so we can be sure that we are sending our secure information to the correct server. Simplifying the SSH Know Host file by centralising it on the Server rather than in each user’s home directory makes sense when wanting the highest level of security.

The video follows where we look at centralizing the SSH Known Hosts file.