Key Files for SSH Connections

Understanding SSH is an essential part of being a Linux administrator. It's the main tool used to connect to an instance of the operating system to get the command line interface. Nearly every Linux administrator will use this on a daily basis. It has replaced more traditional or now legacy tools such as rlogin and telnet due to the lack of security features for those tools. With that said, SSH is a very robust and secure tool. Let's explore SSH more in depth.

What are SSH Directories?

SSH has two main directory trees. Each has their purpose. Primarily, this has to do with whether it is applicable to the entire system or just the user. In other cases some apply to an SSH server versus an SSH client.

The /etc/ssh/ directory

The /etc/ssh/ path is a system wide configuration. Typically these are the defaults and are rarely changed. Sometimes these may be changed to harden a system or just set company defaults. Major version upgrades may have changes to these as newer versions are released as well and new options are available. Other times older options are deprecated or removed.

Within this directory are two main files, ssh_config and sshd_config.

The ssh_config file is for client based connections outbound to servers. This is where any company standards/defaults are inserted into or modified. You can also review this file to see what any factory defaults are for outbound connections.

The sshd_config is where SSH server side settings are set for any system receiving SSH connections. Items like whether to permit root login is accepted or what ciphers are allowed are set here. Also, options like user-specific access as discussed further on are set here.

The ~/.ssh/ directory

This is a user specific directory for a particular user's ssh configuration. Many times this configuration has private keys, accepted public keys and configuration options on various remote connections. The tilde (~) is an alias for the current user's home directory so ~testuser would typically point to /home/testuser.

The known_hosts file is one of the basic level security features of SSH. Each time you connect to a new server, it will prompt you as to whether you accept the remote server's identity. If you answer yes, it appends that information to known_hosts. This can help later down the line if that identity information changes as it can detect an unexpected change or Man In the Middle Attack where someone tries to hijack your connection.

Instead of using passwords, SSH allows you to use key based authentication. We'll discuss how to generate that later with ssh-keygen but for this to work, you have a private key and you share the public key with the server in the authorized_keys file. Once you append your public key to that file, it will accept your key based authentication.

When a key is successfully generated, by default the private key is generated with name id_rsa (for RSA keys). The complementary public key is named id_rsa.pub. The public key can be shared without issue but the private key should be highly secured and never shared.

What are SSH Commands?

Most everyone knows the "ssh" command as it’s used to connect to various servers. There are more commands though and they are not always used on a day to day basis. Some of these are absolute necessities while others are nice to have helper commands.

ssh-copy-id

The ssh-copy-id command, while not strictly necessary, does make life easier. It is one of those helper commands mentioned. What it accomplishes is that it can copy your public key to a server for you. Because the key is not yet on the server, it will likely fall back to password based authentication to do that copy but allow subsequent connections to be via key authentication.

The manual way of doing this is to ssh in and manually edit the authorized_keys file and append your public key. Sometimes you may need to create the authorized_keys if it does not already exist. You then need to ensure it has proper permissions. The ssh-copy-id command handles all of this for you and therefore is much less error prone.

ssh-keygen

The ssh-keygen command is the native way of creating a public and private key pair. There are other tools to do this, namely 3rd-party tools but it is typically guaranteed this command will be on any Linux-based machine. Normally you can accept the defaults such as where to place it and the passphrase to use. Bear in mind that it may overwrite an existing key pair if the default already exists. You can rename these and most people typically do. In that case though you need to specify the new name when trying to use them for various commands like ssh so that it knows which key to reference.

The passphrase is a great idea but not strictly required. Without it though, anyone that gains access to the private key can connect without any other authentication unless multifactor authentication is enabled. For this reason it is best to have a passphrase enabled to protect the key.

ssh-add

When using key-based authentication, it can be a pain to constantly enter your passphrase. After all, you should be protecting your private key with one but fear not, there is a solution to this. There is a key agent that can run and allow you to store those keys in memory with the passphrase already entered. The ssh-add command allows you to enter those private keys into the agent and "unlock" them. There are various security settings that can be used with ssh-add, such as the option to limit the amount of time it is stored in the agent.

Let’s Look at SSH Technology

Let's look under the hood at SSH  and explore some of the technology that helps make network connections and transmission more secure.

User-specific access

By default, anyone that has a valid set of credentials on a server can connect via SSH. For organizations with stricter access controls, this may not be ideal. If you wish to override the default of allowing all users, you can use the AllowUsers and AllowGroups configuration option in the sshd_config file. In more recent versions you can also whitelist users by IP so for example if you only expect a set of users to come in via a certain IP range, you can specify that as well. For example "AllowUsers testuser@192.168.0.0/24" allows the testuser to connect from the 192.168.0.0/24 subnet.

Keep in mind that you will need to restart sshd for these settings to take effect. Restarting sshd will depend on your distribution. In any case, this is a great security feature for locking down servers to specific sets of users and ensuring only those that should have access do have access.

TCP wrappers

TCP wrapper is not specific to SSH but generic to UNIX/Linux. Each server daemon needs to implement it but essentially it is the ability to allow or deny access based on IP address. The files used for this are /etc/hosts.allow and /etc/hosts.deny

For example, if your SSH server is directly on the internet but you want to limit the source IPs that can connect to it, you can add those specific permissions to the hosts.allow or if you have some malicious traffic you can block them in hosts.deny. Traditionally this would be done in a firewall but the Linux systems administrator may not always have access to the firewall or the network team in as timely of a fashion as necessary.

Final Thoughts

Through this post, we have walked through a high level of SSH and some of the commands a system administrator will need to be familiar with. These tools have come a long way over the years, particularly since their predecessors. The SSH suite of tools encompasses more than just what we have gone through and it is highly recommended that you get familiar with the entire suite of tools and commands. They will come in very handy over your years of use in the Linux world.