If you are a Linux administrator, you know the value of Secure Shell. Without this tool, remoting into a Linux server (or sending files via a secure channel) might pose quite the challenge. Then you get SSH, and you can use it without thought. But for those new to Linux administration, you might not quite understand how SSH works. Sure, you can probably sit down at a machine and issue the command:
You’ll log in, and you can do your work. What goes on behind that connection? What are the pieces that make it work?
I thought it would be a good idea to break SSH down to the four most important files for SSH connections, so you can start using the tool with a better understanding of how it works.
Let’s take a look at those key SSH files.
SEE: Information security policy template download (Tech Pro Research)
This is a very important file for SSH. The ~/.ssh/known_hosts file contains the SSH fingerprints of machines you’ve logged into. These fingerprints are generated from the remote server’s SSH key. When you secure shell into a remote machine for the first time, you are asked if you want to continue connecting (Figure A).
When you answer yes to this question, the remote host fingerprint is then saved to the known_hosts file. That key will appear as a random string of characters. Each entry will begin with |1| (Figure B).
What happens with the connection is this:
- You attempt to make the connection to the remote server, via the client.
- The remote server sends it’s public key to the client.
- The SSH client searches for the key fingerprint in ~/.ssh/known_hosts.
- The SSH client loads and verifies the key.
- User authentication takes place
- If authentication is successful, you are logged into the remote machine.
Again, during that connection process, if the remote fingerprint is not found, the SSH client will ask if you want to continue, and (when you say yes) save the fingerprint to ~/.ssh/known_hosts.
Within the ~/.ssh directory, there’s another file called authorized_keys. This is very different than the known_hosts file. What authorized_keys houses are all SSH authentication keys that were copied to the server, from remote clients. This is used for SSH Key Authentication (See: How to set up ssh key authentication).
To make key authentication work, the public key of the client is copied into the ~/.ssh/authorized_keys file on the remote server. The easiest way to do that is by using the ssh-copy-id command on the client like so:
You will be prompted for the remote user’s password. Upon successful authentication, the public key from the client is copied into the ~/.ssh/authorized_keys file on the remote server. If you open that file, you’ll see each entry begins with ssh-rsa and ends with the username@hostname of the client machine (Figure C).
Once that key is saved in authorized_keys (on the remote server), you can then log into that server (from the client whose public key has been saved) with SSH key authentication.
The /etc/ssh/ssh_config file is the file used for system-wide client configuration for SSH. The configurations found here only come into play when the ssh command is used to connect to another host. Most often, you will not need to edit this file.
The /etc/ssh/sshd_config file, on the other hand, is the configuration file for the SSH daemon. This is where you configure the likes of:
- Default SSH port.
- Public Key Authentication.
- Root login permission.
- Password authentication.
Say, for example, you want to only allow key authentication and disable password authentication. On the remote server you’d edit the sshd_config file like so:
- Change #PubkeyAuthentication yes to Pubkeyauthentication yes.
- Change #PasswordAuthentication yes to PasswordAuthentication no.
Once you’ve made those changes, restart the ssh service, and the remote server will only allow connections from client machines with an entry in ~/.ssh/authorized_keys. No entry in the remote server’s authorized_keys file? No access.
Know those files
You are better armed to make use of the SSH tool with an understanding of the above four SSH files. Do you need to know how these files function? Not really. But as an admin, you are best served when you know the tools you use with more than a cursory knowledge.
For more information, read the following man pages: