Tighten SSH access using short-lived SSH Certificates

SSH access using public private key based authentication has several drawbacks that could potentially compromise your organization’s SSH access security. SSH certificate based authentication is a great alternative that addresses most of these security problems. However, the biggest pain point for enterprises using SSH certificate based authentication is managing and renewing SSH certificates for hosts and users at scale. BastionXP SSH Certificate Manager(CA) automates and simplifies the SSH certificate management while offering additional security services such as short-lived SSH certificates, SSH session recording, monitoring, logging and tracking functionalities for auditing purposes.

Is your team still using SSH public private key based authentication to SSH login to your servers and cloud resources? Tighten SSH access to your cloud resources using SSH certificates.

Traditionally, enterprises use SSH public private key based authentication for SSH login to servers — both in-house and in the cloud.

Usually, IT admins create, copy and set up the SSH public private keys for each host (host key) when the VM or server is brought into service. Similarly, IT admins set up the SSH public private keys for each user (user key) who needs to gain access to the VM or server. Sometimes, they even use a homegrown tool to create and distribute SSH keys.

Problem:

Setting up a SSH public private key requires so much time and effort. The admins need to meticulously create, copy and set up a public private key for each user (and also for each host) without leaving any relic anywhere. For example, the user public key needs to be appended to the host machine’s ‘~/.ssh/authorized-keys’ file and the user private key needs to be copied to a folder (~/.ssh/) in the user’s device such as laptop or desktop. Note that the user public key needs to be copied to each and every host that the user needs access to. As a result, the server and user onboarding process is usually laborious, slow and cumbersome.

Here are some security issues associated with using SSH public private key based authentication for SSH login:

1. Copy of an SSH key pair left undeleted in emails or local folders or shared online storages, while copying to the host or the user’s machine.
2. SSH keys don’t have an expiry date or validity period stamped in them. So they can be used perpetually. The technology doesn’t force the admins or users to rotate the keys periodically. As a result, there is no real urge to renew SSH keys periodically. Secondly, rekeying and distributing the keys to servers and user machines at scale requires significant planning and execution. This builds up the inertia against rotating the SSH keys periodically.
3. Some users use the same SSH key pair to login to multiple host machines, potentially increasing the attack surface for any unwanted user who gains access to such an SSH key.
4. When users connect to a server for the first time, weird cryptic messages are shown to users to identify the host key fingerprint and accept it, so that the host key is stored permanently in the ‘known_hosts’ file (~/.ssh/known_hosts) for future references. Mostly, users blindly accept the message and continue with the login anyway, without bothering to know the authenticity of the host they are trying to log in. The only way to address this security problem is to pre-populate the “known_hosts” file with the host public keys of all known hosts that the user would potentially login to. In large organizations, this list is huge and changes over time, which means the ‘known_hosts” file on each user’s machine should be kept updated as well. As a result, most IT teams don’t follow this approach.
5. SSH keys don’t have the hostname or username stamped in them. As a result, any host that is setup with the SSH key could pretend to be the actual host.
6. When users leave the organization, SSH keys assigned to them are usually not deleted from the “authorized_keys” file in all the host machines.

Solution:

The solution to all the above security problems is to use SSH certificates for SSH login and authentication.

How SSH Certificate based authentication works:

Each organization sets up a Public Key Infrastructure (PKI) to issue SSH certificates to its hosts and users. Certificate Authority(CA) is the prime component of a PKI. For SSH certificate based authentication, two CAs need to be created — a Host Certification Authority(Host CA) and a User Certification Authority (User CA). Host certificates are signed by the Host CA and the user certificates are signed by the User CA.

A host certificate and the corresponding private key needs to be stored in the host machine only. Similarly, a user certificate and the corresponding private key needs to be stored in the user machine only. User certificates need not be copied to the host machines and host certificates need not be copied to user machines, unlike the SSH public private key based authentication.

Advantages of SSH certificate based authentication over SSH public private key based authentication:

1. It is sufficient to copy just the user CA certificate to the host machines and the host CA certificate to the user machines. All the users’ certificates need not be copied to all the host machines and all the host machines’ certificates need not be copied to all the user machines.
2. SSH certificates have an expiry date and validity period stamped in them. So, all SSH certificates will eventually expire sometime in the future. The need to rotate SSH certificates periodically is built into the technology. An organization’s security policy could decide the lifetime of a certificate issued to its hosts and users.
3. SSH certificates can be issued to a specific identifiable entity within an organization. So SSH certificates have the host or user name stamped in them to identify who owns the certificate. Role based access control (RBAC) is possible with SSH certificates.
4. When a user connects to a server for the first time, no weird cryptic messages will be displayed on the screen to identify the fingerprint and trust the host key. The authenticity of the host the user is trying to connect to will be automatically verified using the Host CA Certificate stored locally in the user’s machine.

Drawbacks of SSH certificate based authentication:

Though, SSH certificate based authentication addresses most of the security problems in the SSH public private key based authentication, it still has the following caveats in it:

1. SSH private keys still need to be copied to the corresponding host or user machines without leaving any traces of them anywhere.
2. Rotating or renewing certificates takes time and effort to distribute them. Anyone who gets hold of an SSH certificate could login to a host without any issues. Short-lived user certificates are highly secure because it reduces the duration of the damage any unwanted user who holds such a user certificate could cause. However, short-lived certificates require more frequent rotations and therefore more effort from the admin teams. Long-lived certificates have the same inherent security risk as the SSH public private key based authentication but requires reduced effort from the admin teams.

BastionXP SSH CA Solution:

BastionXP SSH Certificate Manager has a built-in PKI and CA that uses Single-Sign On (SSO) with Multi-Factor Authentication (MFA) to automatically generate and distribute short-lived user SSH certificates to hosts and users.

User SSH certificates expire in 8 hours by default and can be configured to suit an organization’s security policy, to any value like 2 hours or 4 weeks or 30 secs or so.

Once users use the SSH certificate to login to a host, they can continue with that SSH session for any longer even if the certificate expires. But, if they exit from the SSH session and need re-login, the users need to SSO login again using their MFA credentials to generate a new SSH certificate.

Because user SSH certificates are short-lived, no certificate cleaning or housekeeping is required in the host or user machines, when a user leaves an organization or when teams get dismantled. The user certificate becomes invalid the next day.

BastionXP Bastion Host Solution

Features offered by the BastionXP SSH Certificate Manager

BastionXP SSH CA solution also offers the following features in addition to the SSH certificate management:

1. All SSH sessions are recorded and stored for auditing purposes. SSH sessions can be replayed and viewed like a video playback.
2. Audit logs are generated and stored when a user or admin accesses any resource.
3. SSH session live screen sharing with team members. Members can join and leave the session at will.
4. Easily rotate CA certificates, host and user certificates when a security compromise is detected.
5. Role Based Access Control (RBAC) to configure policies that decide who can access what resources in an organization.

Conclusion:

SSH public private key based authentication is prone for security breaches as it doesn’t have an expiry date and user or host identity associated with the keys. SSH certificate based authentication addresses several drawbacks of SSH public private key based authentication.

BastionXP SSH CA solution automates and simplifies the SSH certificate management while offering additional security services such as SSH session recording, monitoring, logging and tracking functionalities for auditing purposes.

Download and try BastionXP SSH PKI/CA for free.

Note: This article was originally published at: https://www.bastionxp.com/blog/tightening-ssh-access-using-short-lived-ssh-certificates/