Authentication Methods and Their Order in SSH

1. Introduction

The ubiquitous Secure Shell (SSH) protocol offers many authentication methods. Since some are considered more secure than others, priority matters when it comes to the order in which the connection attempts them.

In this tutorial, we discuss SSH authentication methods and their order when establishing a session. First, we go over former and current ways to authenticate. Next, we look at the options that enable them. After that, we explore options that tell the SSH server to require specific authentication methods in order. Finally, we briefly mention the SSH client preferences option when it comes to authenticating.

For brevity and security reasons, we only consider the newest iteration of SSH version 2 (SSHv2) as implemented by OpenSSH.

We tested the code in this tutorial on Debian 11 (Bullseye) with GNU Bash 5.1.4 and OpenSSH 8.4p1. It should work in most POSIX-compliant environments.

2. Authentication Methods

According to the environment, given ways to authenticate may not be adequate choices, while others can be mandatory. This is why SSH has attempted and attempts to support a wide range of different methods and options:

• ChallengeResponseAuthentication yes no
• DSAAuthentication yes no
• GSSAPIAuthentication yes no
• HostbasedAuthentication yes no
• KbdInteractiveAuthentication yes no
• KerberosAuthentication yes no
• PasswordAuthentication yes no
• PubkeyAuthentication yes no
• RhostsAuthentication yes no
• RhostsPubkeyAuthentication yes no
• RhostsRSAAthentication yes nopwd no
• RSAAuthentication yes no

Importantly, most of these options must be set on both the SSH server and the client. Let’s briefly touch upon the available authentication methods.

2.1. DSA and RSA

The Digital Signature Algorithm (DSA) and the Rivest-Shamir-Adleman (RSA) algorithm are both strong ways to encrypt data. Usually, DSA decrypts and signs faster, while RSA is faster when it comes to encryption and verification.

Yet, both DSA and RSA can contain weaknesses and pitfalls. Perhaps one of the main issues with RSA is that the security benefit from longer keys diminishes much faster than the increase in computational power required. However, DSA has been entirely deprecated in SSH due to catastrophic weaknesses.

Meanwhile, PubkeyAuthentication replaces DSAAuthentication and RSAAuthentication.

2.2. rhosts (Deprecated)

For backward compatibility, SSH supported the rlogin methods of authentication:

• $HOME/.rhosts on the individual user level
• /etc/hosts.equiv on a system level

Both files are responsible for allowing and denying hosts and users passwordless remote access to a system based on names and IP addresses. Considering the ease with which we can, e.g., spoof an IP, none of these options are recommended, and they are also deprecated:

• RhostsAuthentication yes no
• RhostsPubkeyAuthentication yes no
• RhostsRSAAthentication yes nopwd no

Since the functionality is still part of some networks, SSH introduces a replacement.

2.3. HostbasedAuthentication

As its name implies, host-based authentication relies on the same principle as rhosts above: protection on the basis of characteristics rather than secrets. Similarly, several files are involved in the setup:

• /etc/ssh/ssh_known_hosts
• /etc/ssh/ssh_config
• /etc/shosts.equiv, /etc/hosts.equiv (server-only)
• /etc/ssh/sshd_config (server-only)

To reference this method, we use the hostbased keyword.

Critically, the method is rarely recommended outside closed networks due to its many weak points.

2.4. GSSAPI and Kerberos

Generic Security Services Application Program Interface (GSSAPI) is an abstraction that makes other security methods, such as Kerberos, pluggable.

The relevant reference is gssapi-with-mic, while the configuration file options are GSSAPIAuthentication and KerberosAuthentication. Commonly, we enable GSSAPI along with Kerberos, but the latter still requires a specific setup.

2.5. Keyboard Interaction and Challenges

The ChallengeResponseAuthentication is a deprecated and somewhat equivalent version of KbdInteractiveAuthentication. On the other hand, the latter allows the use of a keyboard to authenticate a given session. Specifically, it encompasses several methods to do so.

Specifying keyboard-interactive references this method.

One type of keyboard-interactive authentication is a password.

2.6. PasswordAuthentication

Of course, password authentication is self-explanatory and requires the standard username and password combination to allow users to log in. Due to its widespread use, the default is yes. Setting PasswordAuthentication to no disables password logins.

When using none as a method specification, passwordless accounts can log in as long as we enable PermitEmptyPasswords. In addition, we reference password authentication via password.

Since passwords can be weak and more easily compromised, SSH keys are preferable most of the time.

2.7. PubkeyAuthentication

Indeed, SSH public key authentication is the de facto standard for security. In fact, not using keys is bad practice in most situations.

Because of this, the key generation and setup procedure is streamlined, and the default value of PubkeyAuthentication is yes. Moreover, OpenSSH supports a huge list of algorithms that a system can accept (PubkeyAcceptedAlgorithms).

Naturally, publickey is the reference for this authentication method.

2.8. Deprecation and Changes

Since security is and should be an ever-evolving field, authentication methods and encryption algorithms can come and go. Importantly, knowing what is and isn’t secure at a given time can mean the difference between a protected and compromised system.

To that end, OpenSSH provides a list of release notes that include critical changes, fixes, and deprecation warnings.

Now, let’s understand how SSH handles the selection and order of authentication methods.

3. Order and Prefer Authentication Methods

Until now, we discussed different forms of authentication and which option enables each. However, we can also order, require, and prefer them on the server and client.

Let’s summarize the authentication method references and which options they pertain to:

• gssapi-with-mic: GSSAPIAuthentication
• hostbased: HostbasedAuthentication
• keyboard-interactive: KbdInteractiveAuthentication
• none, password: PasswordAuthentication
• publickey: PubkeyAuthentication
• any: any enabled method

To order given methods, we can use AuthenticationMethods in /etc/ssh/sshd_config. Moreover, PreferredAuthentications in /etc/ssh/ssh_config set our client preferences. Each option is to be followed by a comma-separated list of one or more references, where any must appear alone if used.

3.1. AuthenticationMethods

Critically, the AuthenticationMethods option sets the authentication methods required to complete in order before permitting access to a user.

By default, we have any, meaning we can use any single method to log in. Hence, AuthenticationMethods is either not present at all or just a comment in /etc/ssh/sshd_config.

To override the default, we can add a line like the following to the configuration:

$ echo 'AuthenticationMethods password,publickey' >> /etc/ssh/sshd_config

Here, we expect the user to first complete a password challenge, followed by a public key authentication. Of course, both have to be successful for access to be granted.

In fact, we can add alternatives:

AuthenticationMethods password,publickey password,hostbased

In this case, we always begin with password authentication but can continue with either a public key or host identification. The latter two would not be available until a successful password entry.

Finally, when we repeat publickey,publickey, users need two different public keys to match in order to gain entry.

Importantly, any authentication method in these options must be allowed. This includes configurations like PermitRootLogin as well.

3.2. PreferredAuthentications

Similar to the previous option, clients can use PreferredAuthentications to specify the order in which they try authentication methods. Unlike the list after AuthenticationMethods, preferences don’t equal requirements.

PreferredAuthentications just enables clients to pick methods that are offered by servers. The default preference list is gssapi-with-mic,hostbased,publickey,keyboard-interactive,password.

Let’s consider an example with a server that has the following configuration:

HostbasedAuthentication yes
AuthenticationMethods password,hostbased password,publickey

Now, we can connect with our client:

$ ssh -o PreferredAuthentications=publickey,password,gssapi-with-mic,hostbased
  keyboard-interactive user@baeldung

Here, we supply our preferences with the -o flag, which allows us to specify additional option lines to the /etc/ssh/ssh_config file. Since publickey precedes hostbased in the preference list, the client would attempt the former when the server offers the choice.

4. Summary

In this article, we looked at SSH authentication methods, ways for servers to require them in order, and for clients to prefer some to others.

In conclusion, knowing how to order authentication methods introduces another layer of security to the golden standard, which is SSH.