In a world full of Linux servers, containers and clients, SSH is one of the most used and most less understood protocols. Newer services such as related to container tooling, SSH over SSL have further abstracted away this protocol. But nevertheless, SSH continues to remain the primary means of establish connections with linux based operating systems and perform routine system administration and management related tasks. It also continues to be base of other important protocols / services such as SFTP, SSH tunneling, Virtual Private Network etc. This blog is first in series of blog posts about SSH or secure shell protocol, where we’ll discuss most of the things one should know about SSH. You can find the series index here.

SSH Overview

It provides a mechanism for authenticating a remote user, transferring inputs from the client to the host, and relaying the output back to the client, all over a text based interface. Being a text based interface, it is very fast since the data which needs to be transferred is very less over the network. When someone logs into a linux machine using SSH, one logs in an account that is already present and configured to login on the remote machine. Once the connection is established, all communication happens over an encrypted channel, henceforth the name, secure shell.

The SSH connection is implemented using a client-server model. This means that the remote machine, where one wishes to logon, must be running a specialized software called SSH server. It is sometimes also called as SSH daemon. This software is responsible for listening on a specified network port, negotiate connection protocols, generate encryption keys, authenticate users, spawning the shell configured for the users, etc.

Clients must be running a specialized piece of software called SSH client. This software is responsible for initiating connection with SSH server, passing client information such as username and keys, negotiating connection protocols, specify certain details about sessions, etc.

There are many different types of clients and servers available from the different software vendors. You can do a quick search in your favorite search engine and you will find many. However, Linux-based operating systems have SSH client in-built which can simply be initiated by ssh command. The syntax for establishing an ssh session is:

ssh username@remote_host

where username represents the account that is present on the remote machine and remotehost represents the IP address or fully-qualified DNS name of the remote machine.

How SSH Authenticates Users

For the new users, the most common authentication mechanism is by making use of passwords. However, the SSH protocol does not place any restrictions on number of times a client can attempt to login or any criteria such as complex password mechanism etc. This makes it easy for malicious entities to automate the login using brute force mechanism using passwords based on some criteria and try to gain access. So passwords based authentication mechanism is generally considered to be less secure and not recommended.

Another common mechanism is by making use of the public key authentication method. It is primarily used for automation and many a times by system administrators for single sign-on. The idea is to have a asymmetric cryptographic key pair – public key and private key – and configure the public key on a server to authorize access and grant anyone who has a copy of the private key access to the server. The public key can be shared freely without concern, while the private key must be vigilantly guarded and never exposed to anyone. The keys used for authentication are called SSH keys. Public key authentication is also used with smartcards, such as the CAC and PIV cards used by US government.

PKI certificates can also be used for authentication. In this case, the user still has a private key but also has a certificate associated with the key. The technology is supported in both Tectia SSH and OpenSSH, with some differences.

Authentication using SSH key pairs

To authenticate using SSH keys, a user must first generate an SSH key pair on their local computer. The generated public key must be copied to a file within user’s home directory at ~/.ssh/authorized_keys. This file may contain a list of public keys, one per line, that are authorized to log into this account.

When a client connects to the host, wishing to use SSH key authentication, it will inform the server of this intent and will tell the server which public key to use. The server then checks its file authorized_keys for the public key, generates a random string, and encrypts it using the public key. This encrypted message can only be decrypted with the associated private key. The server will send this encrypted message to the client to test whether they actually have the associated private key.

Upon receipt of this message, the client will decrypt it using the private key and combine the random string that is revealed with a previously negotiated session ID. It then generates an MD5 hash of this value and transmits it back to the server. The server already had the original message and the session ID, so it can compare an MD5 hash generated by those values and determine that the client must have the private key.

Generating and Working with SSH Keys

Generating an SSH key pair

A number of cryptographic keys can be used to generate an key pair. Some of the popular options are RSA, DSA, and ECDSA. RSA is the most popular and default one. The simplest way to generate a key pair is to use command ssh-keygen without arguments. In this case, it will prompt for the file in which to store keys. Here’s an example:

This prompt allows you to choose the location to store your RSA private key. Press enter to leave this as the default, which will store them in the .ssh hidden directory in your user’s home directory. Leaving the default location selected will allow your SSH client to find the keys automatically.

The next prompt allows you to enter a passphrase of an arbitrary length to secure your private key. By default, you will have to enter any passphrase you set here, every time you use the private key, as an additional security measure:

If you do choose to enter a pass-phrase, note that, by default it will display nothing. This is more of a security precaution. After this, it will proceed to generate an RSA SSH key pair, located in the .ssh hidden directory within your user’s home directory:

As you can see in the output, the public key is saved as ~/.ssh/id_rsa.pub and associated private key as ~/.ssh/id_rsa. The public key is what needs to copied to the remote machine, where you need to ssh.

Choose different SSH algorithm and Key Size

Once a key pair is generated, its algorithm cannot be changed. So you need to be careful about the algorithm. Some of the options are as below:

• RSA – Default and most popular algorithm. It is based on the difficulty of factoring large numbers. A key size of at least 2048 bits is recommended for RSA; 4096 bits is better. RSA is getting old and significant advances are being made in factoring. Choosing a different algorithm may be advisable.
• DSA – An old US government Digital Signature Algorithm. It is based on the difficulty of computing discrete logarithms. A key size of 1024 would normally be used with it. DSA in its original form is no longer recommended.
• ECDSA – A new Digital Signature Algorithm standardized by the US government, using elliptic curves. This is probably a good algorithm for current applications. Only three key sizes are supported: 256, 384, and 521 (sic!) bits. Most SSH clients now support this algorithm.
• ED25519 – This is one of the new algorithms added in OpenSSH. Support for it in clients is not yet universal. You need to check the documentation of the SSH clients and servers, if they support this algorithm.

The algorithm is selected using the -t option and key size using the -b option. The following commands illustrate:

ssh-keygen -t rsa -b 4096
ssh-keygen -t dsa
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

Choose the keypair file name

If you do not want the ssh-keygen to prompt you for the filename, you can supply it using -f option. For example:

ssh-keygen -f rsa_lon_4096

There are a number of other options available for ssh-keygen command. You can use man ssh-keygen to review them and proceed accordingly. In the next blog post, we’ll discuss how to copy the public key to the remote machine and few other considerations.