Using SSH is a common method in Linux to remotely connect to your servers / desktops and is secured though encryption. The data will always be encrypted but 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”.
The Server’s Public Key.
The default behavior of the SSH client on SUSE Linux is to ask if you want to accept the Server’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. 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.
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, have their Public Key or Certificate stored in our key-store. The configuration file used to control this is:
/etc/ssh/ssh_config
We need to make sure that the setting for StrictHostKeyChecking is set to yes to ensure we only connect when we have a pre-shared key.
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 known_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.