Client authentication is the final phase of SSH session establishment.

While password authentication is the most popular, SSH has several other authentications methods.

Some, like keyboard-interactive authentication are more suitable as enhancements to password authentication. Others, like certificate-based authentication are more secure and scalable, and can replace password-based authentication in environments demanding tights security controls to be enforced.

Let's go through these SSH authentication mechanisms now.

#1: Password authentication

Password authentication is simple and straightforward.

The user provides a username and password to the SSH server and the server verifies these credentials against its local user database or an external authentication system (like LDAP).

If the credentials received from the client, matches the credentials stored at the server, the client authentication is successful.

Pros:

• Simple and easy to setup.

Cons:

• Less secure than other methods due to the vulnerability of passwords to brute-force attacks and keylogging.

#2: SSH key based authentication

In key based authentication, the server authenticates a client via asymmetric cryptography.

Asymmetric cryptography algorithms us a pair of mathematically linked keys: a public key and a private key. Anything encrypted with the private key can be decrypted by using the public key and vice versa.

When an SSH connection attempt is made:

1. The server sends to the client a random challenge encrypted with the public key.

2. The client, then decrypt this random challenge using its private key, create an MD5 hash, and send it to the server.

3. The server create a new MD5 from the original random challenge and compares it with the one received from the client. If they match, it assures the client has the correct private key, corresponding to the public key stored in the host. authentication is successful.

The private key stays at the client and is never transmitted over the network at any time.

Key based SSH authentication generally considered a very secure and convenient method, enabling passwordless SSH login. Also, this is the recommended method for automated SSH logins.

Before establishing a session, a user must generate a key pair, keeping the private key secure on their local machine and placing the public key on the remote server in the ~/.ssh/authorized_keys file.

Pros:

• Not susceptible to brute force attacks.

Cons:

• Need pre-configuration of the keys in client and the server.

#3: Keyboard-interactive authentication

Keyboard interactive authentication is similar to password authentication but more flexible.

In password authentication, the server uses the password as the sole parameter to identify the client.

In keyboard interactive authentication, the server can prompt the user for various forms of input, not just a password. The prompts are presented dynamically by the server, offering greater adaptability compared to simple password authentication.

Often, keyboard-interactive authentication is not used as a standalone authentication mechanism. It's used in multi-factor authentication, such as requiring a password followed by a one-time password (OTP) or a response to a security question.

#4: Host-based authentication

This method allows authentication based on the identity of the client host rather than the individual user.

It relies on the server trusting the client host, typically configured through entries in the /etc/hosts.equiv and /etc/ssh/ssh_known_hosts files in the server.

Host-based authentication is also not used standalone. It's often combined with public key authentication for enhanced security.

#5: Certificate-based authentication

The certificate-based authentication method extends key-based authentication by using digital certificates signed by a trusted certificate authority (CA). The authentication flow in certificate-based authentication looks like this:

1. The CA generates a key pair and share the public key to all SSH servers and clients.

2. Each SSH sever generates an SSH key pair and send the public key to to the CA. The CA signs the public key and send back to the server. This becomes the server certificate.

3. Each user also generate a key pair and send the public key to the CA. The CA signs it and sends back to the client. This becomes the client certificate.

4. During the client authentication phase, the SSH server sends its certificate (the server certificate) to the client.

5. The client verifies the server certificate's signature using the trusted public key of the CA.
   If the certificate is valid, the client then sends its certificate (the client certificate) to the server.

6. The server verifies the client certificate's signature using the trusted public key of the CA.

7. Upon successful validation of both host and user certificates, the client is granted access to the SSH server.

Pros:

• Scalable: In an environment with a large number of servers and users, certificate authentication allows centralized management without copying keys to individual servers.

• Time limited credentials: CA can issue certificates with expiry dates

• Centralized trust: Eliminates the need to distribute and manage individual public keys across multiple servers, as trust is centralized in the CA.

• Enhanced Security: Provides stronger assurance of identity by relying on a trusted third party (the CA).

Cons:

• Require additional infrastructure (CA and a mechanism for clients to request new certificates) in place.

The certificate based SSH authentication is the most secure, scalable, and flexible mechanism for an enterprise network. And it has been adapted by tech teams a decade before.

Then, why many DevOps teams are still relying on password-based authentication.

There are two reasons:

Reason #1 is that most DevOps engineers believe password authentication with a centralized database like LDAP is secure enough.

Reason #2 is a bit more subtle problem. While the functionality required to implement certificate-based SSH authentication is available with open-ssh server, and has been so for a long time, there's no any over-the-shelf solution that you can procure and install to implement this certificate based authentication. Therefore this method is often overlooked by enterprise security teams.

---

As security minded DevOps engineers we must always strive to make things more secure. What authentication method are you currently using?