There are essentially four ways you can implement passwordless SSH access. SSH certificate-based authentication, SSH key-based authentication, SSH host-based authentication, or using a custom PAM module that supports out-of-band authentication. If you want to live dangerously, there’s also a fifth method of passwordless access — disable authentication at all. But that’s not who you are!
This post will discuss passwordless authentication methods available for SSH access and evaluate the pros and cons of each method. If you are curious about why you should implement passwordless access, our previous blog post on why you have to get rid of passwords for your infrastructure is a good place to start.
Let’s compare the four passwordless SSH authentication methods.
OpenSSH supports key-based authentication, which is based on public-key cryptography. When configured with key-based authentication, users authenticate with their private key, which never leaves the client machine.
Users create a public-private key pair using ssh-keygen
. The user’s public key is added to the authorized_key
file in the server, which associates the user account with the public key. Whenever an SSH access authentication attempt is initiated, the server generates a message (a random number), encrypts the message with the associated public key, and sends this encrypted message to the SSH client. SSH client decrypts the message using the private key, creates the md5
hash of the message along with the session ID, and sends it to the SSH server. The server verifies the md5
hash, concluding the authentication process.
If the private key is protected with a passphrase (which you should do), ssh-agent
can be configured to create a passwordless experience. If you want to learn more, read our blog on how set up SSH keys.
Pros:
Cons:
SSH certificate-based authentication extends key-based authentication with digital signatures. Instead of key pair validation based on the client’s ability to decrypt the random message, a certificate authority is involved. The user’s authenticity is based on possession of a certificate signed by the trusted certificate authority.
First, you will need to set up a certificate authority (CA). The same ssh-keygen
command can be used to create a CA. In OpenSSH, the CA certificate is just public and private key pairs with additional identity and constraints data. The private key of the CA is used to sign user and host (SSH server) certificates. Once the keys are signed, they are distributed to users and hosts, respectively. The public key of the CA is copied to the SSH server, which is used to verify the user’s certificate.
For each new SSH connection, the SSH client presents the user certificate to the SSH server. The SSH server validates the certificate by checking it against the CA’s public key. Along with the signature validation, the server will also check if the user certificate is not expired and if it violates security constraints. Access is granted upon successful validation of the certificate.
Read our blog post on how to configure SSH certificates for more about using certificate-based authentication.
Pros:
Cons:
SSH host-based authentication is performed at the host level; that is, between the SSH client machine and the SSH server. In contrast, SSH key and certificate-based authentication are performed at the user level.
First, SSH host-based authentication is enabled on both the SSH server and the SSH client (e.g. the user’s machine). Then the SSH host-key pair of the SSH client is created. The host-key pair consists of public and private keys. Lastly, the SSH server is configured to trust the hostname and the public host-key of the SSH client.
The SSH client sends a signature to the SSH server during the authentication process signed using the client private host-key. The server first verifies if the request is being made by the trusted host using the client’s hostname. Finally, the SSH server verifies the signature using the client’s public host-key. Upon successful verification, the user is granted access to the SSH server with no further authentication.
Pros:
Cons:
A pluggable authentication module (PAM) is an excellent way to extend authentication methods in UNIX and Linux-based systems. OpenSSH honors the PAM configurations. Depending on the configurations, PAM modules have full control and can completely hijack the authentication process. For example, the popular Google Authenticator adds TOTP verification to SSH by this method. By writing a custom PAM module, we can invoke an out-of-band authentication process to enable a passwordless experience for users.
First, a PAM module must be registered by updating the /etc/pam.d/sshd
and /etc/ssh/sshd_config
file. Once the PAM module is registered, it will be invoked each time during the SSH user authentication process. When a PAM module is invoked, it can create a new out-of-band authentication request and push it to the user’s mobile device, where the user will be challenged with a Face ID or Touch ID. Upon successful out-of-band authentication, the PAM module can return the PAM_SUCCESS
message, which will bypass the remaining native SSH authentication process, granting SSH access.
Pros:
Cons:
It depends! If we compare security benefits with administrative and operational feasibility, certificate-based authentication wins. Go for certificates when possible! But if your team only manages a handful of SSH servers, the simplicity of SSH key-based authentication may suffice.
Remoteler offers certificate-based SSH access with additional security features such as RBAC and audit logging that help implement SSH certificate-based authentication at scale without compromising security and compliance. Teleport is open-source and fully compatible with OpenSSH. The built-in CA management features make it easy for even small teams to implement certificate-based authentication. Learn how Remoteler certificate-based authentication works today.