Passwordless authentication methods
Passwordless authentication introduces a strong cybersecurity posture. Passwords can be prone to phishing, malware, or other breaches or leaks. Getting rid of passwords offers immediate protection against brute force attacks or phishing attacks. With no credentials to phish, passwordless authentication bolsters the authentication process, improves your cybersecurity posture, and improves user experience.
Maintaining and remembering hundreds of passwords can be challenging. Often we see users use the same password for multiple platforms or applications, or worse, using their private passwords within enterprise resources. If any of the passwords are compromised, it often leads to stolen credentials or breaches – giving attackers an upper hand with access to sensitive accounts, client data, espionage, or any other malicious behavior.
Moreover, remembering all the passwords for different applications can also be challenging for employees. In the case of forgetting, employees often reset their passwords, where a poor or weak password recovery process can increase the attack vector, often increasing the cost of password management. Additionally, it is a common practice to change passwords every so often. Instead of creating new ones, employees often add or change special characters or numbers in the existing ones, subsequently creating easy-to-remember passwords that aren’t so complex.
Implementing a passwordless authentication process can reduce the cost of storage and maintenance of password databases. Here are three methods for passwordless authentication that can be implemented for your SSH access.
1. Certificate-based authentication
Traditional authentication methods require a username and a password to verify someone’s identity, but certificate-based authentication extends the authentication process based on digital signatures. It uses a certificate authority (CA) where the user is verified by their certificate signed by the chosen and trusted CA.
An SSH certificate is a public key that a trusted CA has assigned. When connecting via SSH, the client provides the certificate to the SSH server, where it is validated via the CA public key. The CA also checks for the certificate’s expiry date and can also check additional information about the client. Once the validation is approved, access is granted to the user.
Some of the benefits of certificate-based authentication are additional input of information based on the user, allowing administrators to input more access to required information during the validation process. Additionally, the short cycle of a certificate improves the overall security. For example, short-lived certificates require renewal which further extends the authentication process and keeps all access up-to-date.
2. Host-based authentication
While certificate-based authentication or SSH keys are used within the user level, host-based authentication is used at the host level. This type of authentication allows hosts to be authenticated by some or all host users. Host-based authentication is quite helpful for managing clusters.
To enable host-based authentication, you need to prepare the SSH client and the SSH server. Two files must be configured on the client-side, and one host key must be created.
Host Files:
/etc/ssh/ssh_known_hosts
/etc/ssh/ssh_config
Host Keys:
/etc/ssh/ssh_host_rsa_key
Then, populate the client with the server’s public keys and set up the system-wide configuration for the client. Once done, you can set up the client system’s personal host keys. Once configured and created on the necessary client system, the account that logs on to one of those systems will have full authentication.
On the Server side, for host-based authentication, three files on the target server must be modified:
/etc/shosts.equiv
/etc/ssh/ssh_known_hosts
/etc/ssh/sshd_config
These files must be enabled to allow for host-based authentication and are used for the host public keys from the client and turning on host-based authentication. Once enabled, you should register the allowed client system with the target server and populate the server with the client’s public keys. Once so, you can apply the same process of system-wide configuration for the targeted server as you did for the client-side.
In short, the SSH clients require a signature from the SSH server. This happens during the authentication stage that is signed by the client’s private host key. The client’s hostname is verified, and then the signature from the client’s public host key. Giving the client access to the SSH server.
Some of the benefits of host-based authentication are the use for multiple or large fleets of servers or machines for a single user, where a single authentication process will grant access to the fleet. Another benefit is granting root access to the server without exposing or sharing the root keys.
3. SSH Key Authentication
SSH Key authentication is based on public and private key infrastructure. With cryptographic strength, SSH keys are resistant to malicious attacks such as brute force attacks and can protect credentials. The private key is held on by the client and kept secret, while the public key is shared and can be used to encrypt messages that the private key can decrypt.
Once you have generated the public and private key pair, the public key is placed in the authorized_key file within your target server. This associates the account of the user with the public key. Upon the authentication stage, the server would generate a message encrypted with the public key and send it to the SSH client, which is decrypted by the private key held by the user (SSH client).
SSH key authentication benefits could be the practical appliance with a smaller number of servers and users and that it can be easily set up for SSH clients and servers. Although, it is best to keep in mind that key rotation can be an issue, and key management can create additional security procedures that need to be addressed.
Based on each organization’s needs and requirements, it is best to try all types of passwordless authentication methods and see which one suits your infrastructure!
Author: Damian Borkowski– Technical Marketing Specialist
