If you want to open access to SSH, and possibly even to users on the Internet, you need to harden authentication, preferably with a combination of key pairs, discoverable and non-discoverable credentials, multifactor authentication, authenticator apps, and other methods. SSH with public key authentication should be your default setting.

Public Key Authentication

To get started, you need to create an SSH key pair with the ssh-keygen command. Even now, the process is fraught with pitfalls: Given that massive attacks on RSA2048 are commonplace, you can expect RSA3072 to become the focus of cryptoanalysts soon. Anyone still using RSA with key lengths of 2048 bits or less needs to take action, urgently.

In this article, I create a key pair with the use of elliptic curves (elliptic curve digital signature algorithm, ECDSA). To find out more about elliptic curve cryptography, please take a look at the English-language paper by the Germany Federal Office for Information Security (BSI) [1]. The type of key pair, whether ECDSA or ED25519, and therefore the choice of curve, has practically no influence on security. Both methods are considered to be very secure; ED25519 delivers slightly better performance under certain conditions.

To begin, generate a key pair for test purposes (Figure 1), upload the public key to the target system, and log in with the new key pair:

$ ssh-keygen -t ecdsa -b 384 -f ~/.ssh/ecdsa_2024-03
$ ssh-copy-id -i ~/.ssh/ecdsa_2024-03.pub thomas@pihole
$ ssh -i ~/.ssh/ecdsa_2024-03 thomas@pihole

Figure 1: Creating an SSH key pair for test purposes.

Having a private key and password to match boosts the level of security. After logging in, you need to edit the /etc/ssh/sshd_config configuration file for the SSH daemon on the target system. You will also want to disable SSH login for root with the PermitRootLogin no option and disable the password authentication option with the PasswordAuthentication no option.

SSH keeps active connections open when the server restarts, which means you can run

systemctl restart sshd

to restart the SSH daemon without locking yourself out. At this point, open another SSH connection as a test to make sure the public key authentication-based login works. This single step,

$ ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no root@pihole

checks whether root login and password-based login still work.

The Second Factor

Public key authentication is an important step. However, a compromised key pair means that unauthorized persons might be able to gain access to the system. Anyone in possession of the private key can try to unlock it; there is no such thing as a separate, second factor. Many of you will be familiar with the time-based one-time password method (TOTP) from Google Authenticator. The sender and recipient initially agree on a shared secret key; after a defined period of time, typically 30 seconds, a cryptographic hash, the one-time password (OTP), is computed on the basis of the secret key and the absolute time.

On Debian and its derivatives, you only need one additional package:

sudo apt install libpam-google-authenticator

You then need to tell the system to request the second factor after a successful authentication by the public key method. Here is where the idea of the pluggable authentication module (PAM) comes into play. As the name suggests, PAM can control authentication to certain services with extensible rulesets. If you get something wrong, you might not be able to log in on the system, so it makes sense to make a backup copy of all files in advance.

After integrating the Authenticator library, enable it in PAM by opening the /etc/pam.d/sshd file in your choice of editor and adding the line:

auth required pam_google_authenticator.so

Also make sure the challenge-response procedure is enabled in the /etc/ssh/sshd_config file. The ChallengeResponseAuthentication yes line is mandatory for TOTP. Finally, restart the SSH daemon by typing:

sudo systemctl restart sshd.service

You now need to set up Google Authenticator; simply launch google-authenticator in a terminal and answer the questions as follows:

$ google-authenticator
Make tokens "time-base": yes
Update the .google_authenticator file: yes
Disallow multiple uses: yes
Increase the original generation time limit: no
Enable rate-limiting: yes

After doing so, you will see a QR code that you can scan with Google Authenticator, as well as some emergency codes.

In principle, the QR code should also work with other TOTP programs, such as KeePassXC. In this case, you need to copy the secret key instead of the QR code. TOTP can be set up in the context menu of the password entry in question. You need to enter the secret key in the matching text box.

The remaining options are just as easy to set up. Use the RFC 6238 option to set the algorithm to SHA-1, the period to 30 seconds, and the code length to six characters. Then, simply enter the TOTP code currently displayed to complete the setup for a genuine second factor on top of your private key.

Highest Hurdles

Hardware tokens seem to be disproportionately widespread among Linux users – at least that was the result of a (not entirely representative) survey at this year's Chemnitz Linux Days. Anyone in possession of a FIDO2 stick [2] can use it for SSH authentication – provided SSH, at least version 8.2p1 or preferably version 8.3, is available on the target system. If you want to use discoverable credentials (formerly known as resident keys), you need SSH 8.3 or later. Up to and including SSH 8.2p1, users are restricted to non-discoverable credentials (previously referred to as non-resident keys).

The difference between discoverable and non-discoverable credentials essentially lies in the storage locations and the associated mechanisms. Discoverable credentials are stored directly on the authenticator itself; that is, they reside there. They can include security tokens such YubiKeys [3], but also Apple Secure Enclaves on the iPhone, hardware security modules (HSMs) on Android devices, or Trusted Platform Modules on a laptop.

The term "discoverable credential" is so called, because the client can determine a list of possible keys in the authenticator that matches the respective relying party ID (rpID), which could be an email address, phone number, or username. Autocomplete only works with discoverable credentials.

Figure 2 shows the login procedure by discoverable credentials. The relying party (RP; e.g., a website) sends a nonspecific authentication request to the client, such as a browser. The client queries the authenticator, a YubiKey in this case, which determines all discoverable credentials for the appropriate RP. In the web browser, you then select the desired discoverable credentials, which in turn are used to sign the request of the requesting party.

Figure 2: The schematic workflow of an authentication procedure by discoverable credentials. This method means you don't have to memorize your credentials.

This example demonstrates one of the benefits of discoverable credentials. Now that the authenticator includes the relevant user handles (email addresses, usernames, phone numbers, etc.), you no longer need to remember them. The handles can be pre-filled. Authentication can also be tied to a specific device (device-specific authentication).

However, the process has its downsides because, even in this age of virtually unlimited storage space, many security keys can only store a very limited number of credentials. As a rule, hardware tokens offer between eight and 100 storage slots for resident keys. If you reach the limit, the content in some of the memory slots must be cleared to create space for new credentials.

Another risk is losing the hardware token. If this happens, all the stored keys are lost, which might mean that you can no longer log in to the services you need. Moreover, you run the theoretical risk that an attacker could manage to extract the stored credentials from a captured security key. Although modern authenticator devices are hardened to prevent this outcome (e.g., mechanisms such as PINs or biometric data to prevent extraction), there is always a residual risk.