SSH Keys allow a secure SSH connection from a client to a host without using passwords. These same keys work with some other communication utilities such as SFTP.
In some instances the reason for using SSH Keys is the convenience of not having to enter passwords. This may also enable some automated connections to function securely because passwords do not have to be included in the automation.
A key reason to use SSH Keys is that it allows disabling a login to a root account (or other sensitive account) with the requirement of a password only – protecting against a malicious root account login using a discovered password.
The first time a client initiates a SSH connection to a host, the client’s user is prompted with information about the host, and the user is asked to agree that it’s the valid host before establishing the connection. Once accepted, a “public key” from the host is stored on the client in a file named known_hosts.
On future connections, the client user is only asked to validate the host identification again is if host sends a public key that no longer matches the one stored in the client’s known_hosts file. This could indicate a security breech.
A key point in properly implementing SSH Keys is knowing that a public key is placed on the client computer and a private key is placed on the host computer. And neither of these keys are the same key that was automatically stored in the known_hosts file used in establishing the identity the host computer.
These SSH public and private keys are typically generated once on the client’s computer using the command: ssh-keygen
The public key is a file generated by the ssh-keygen command – and it’s implemented on the client by simply moving it to the .ssh directory of the client’s user’s home directory.
The private key is a second file generated by the ssh-keygen command. To implement this private key, it has to be appended to host’s known_keys file. This file is in the .ssh directory of the home directory on the host once the connection is established.
There are several way to append the private key file to the host’s known_keys file. The first article referenced below describes this process using the ssh-copy-id command.
It can also be done by first getting a copy of the private key file from the client to the host computer (via ftp, email, etc.) and then using standard UNIX commands to append the contents of the private key file to the known_keys file.
For example: cat private_key_file >> known_hosts
For examples of these procedures, with use of some of the command options, the following references are suggested:
- https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys–2
- https://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files
In the case where a host experiences a change of it’s SSH public key (such as re-installing the operating system on a machine) a SSH connection will be prevented do to risk of “man in the middle” security breech. This is addressed and corrective actions offered here: