Tighten SSH access using short-lived SSH Certificates


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.

  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.


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.

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 Bastion Host Solution:

BastionXP Bastion Host solution 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 end user machines. User SSH certificates expire in 8 hours by default and can be configured to suit an organization’s security policy, to any value like 4 weeks or 30 secs or so.

Components of the BastionXP Bastion Host Solution:

BastionXP Bastion Host solution has three components:

  1. Bastion Host or SSH Proxy with CA
  2. BastionXP SSH Server,
  3. BastionXP SSH client/authentication utility

BastionXP Bastion Host Deployment Option #1 — CA Only Mode

In the CA only mode of deployment, BastionXP Bastion Host will function only as a CA server to manage the SSH certificates. SocketXP Bastion Host’s SSH proxy mode (or Jump Host) functionality will be disabled. An OpenSSH server (already in place) will perform the Jump Host functionality.

BastionXP Bastion Host Deployment Option #2 — SSH Jump Host + CA Mode

In this mode, BastionXP Bastion Host will replace an OpenSSH server functioning as a Bastion Host or Jump Host. BastionXP Bastion Host will function as the SSH proxy server or Jump Host, in addition to performing the CA functionality for SSH certificate management. However, the hosts residing behind the Jump Host will still run the OpenSSH server and the user machines will continue to use the OpenSSH client. SocketXP Bastion Host can interoperate seamlessly with OpenSSH servers running in the host machines and the OpenSSH clients running the user machines.

BastionXP Bastion Host Option #3 — Pure Play Mode

In the pure play mode, BastionXP software will run everywhere in the network as an SSH server, SSH client and as an SSH Jump Host/CA server. The diagram below explains this mode of operation.

BastionXP Bastion Host Solution

Additional features offered by the BastionXP Solution Vs. OpenSSH Solution

BastionXP Bastion Host 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, and ofcourse, 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.


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 Bastion Host 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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ganesh Velrajan

Ganesh Velrajan

Ganesh Velrajan is the founder of Ampas Labs Inc. Learn more about our SSH Remote Access Solutions at https://www.socketxp.com and https://www.bastionxp.com