Let's get definitions out of the way first. I'll broadly describe SSH and several application use cases, then focus the conversation around SSH Keys for interactive user login sessions.
The use cases mentioned above revolve around two actors communicating over the wire. However, this raises the issue of trust and the need for mutual authentication—the client authenticating the server and vice versa. Therefore SSH includes authentication mechanisms enabling the client to authenticate to the server. There's the basic password and a more advanced public key authentication method with two variants.
We've used SSH for decades as the de-facto way to access remote systems over an unsecured network such as the internet—something commonplace with so much of the workforce working from home. EdgeScan's 2021 Vulnerability Statistics Report showed a 40% increase in exposure related to remote access using insecure SSH and RDP credentials.
From an administrative perspective, a core driver is the ease of use and productivity. More specifically, how quickly and efficiently your admins can access dozens or hundreds of remote systems. Although Windows machines are constantly the center of security attention, more organizations are deploying Linux and Unix (*NIX) machines.
These are open source, making it possible to spin up systems quickly at a minimal cost. As the *NIX estate expands, so do administrative duties. Using an SSH client that supports single-click login (single sign-on (SSO) to remote systems is highly prized. Note that Microsoft has also made SSH work properly on Windows machines to enable rapid remote access to a command line or PowerShell prompt on remote systems.
Although SSH can also be used for operational automation, for example, cron jobs, we will focus instead on the human user and interactive session use case.
Every SSH keypair represents a potential attack vector, increasing your threat surface. The public and private keys persist on disk and are permanently trusted. It's a common practice for admins to install a public key into the "root" home directory of all servers they need to access, thus simplifying login across all systems. But if a single private key is compromised, the adversary can gain uncontrolled access to any *NIX system with the public key installed and move laterally. Also, if you enable vendor SSH access, their weaker protection for private keys impacts your risk profile.
Although the crypto theory behind public/private keys is sound, the SSH key management and lack of IT/security oversight and control represent the most significant risks. SSH keys suffer from being easily created on-demand by individual admins and shared with admin team members. If they're not properly secured and managed, you risk them falling into the wrong hands.
From an ops perspective, SSH key management challenges exacerbate as the *NIX estate scales. The effort is akin to PKI key management. It requires effective methods to create and safeguard keypairs, provision the public key to each system, distribute the private keys securely, de-provision when no longer in use, and handle replacement when a private key is lost or compromised. There's also the fear of removing/rotating a key that might break a critical service.
Many organizations don't have a formal SSH key management ops function
SSH key management should be part of an organization's access and IT risk management program. However, many don't have a formal SSH key management ops function. That puts the onus on individual admins to do it all manually, and the experience is far from ideal. The user must deal with SSH clients, keys, key distribution, cryptic errors, and security warnings from SSH client apps.
Organizations must comply with regulations such as HIPAA, PCI DSS, and GDPR to protect data security and privacy. SSH key management plays a critical role in meeting these requirements. Also, not having a complete account of public keys matched to their corresponding private key owners is an audit and compliance concern. An admin sharing private SSH keys compounds this, making establishing and tracking accountability difficult.
If you plan to continue using SSH keys, you can assume operational control over them with the help of PAM. A credential vault like Delinea’s Secret Server handles SSH key discovery, protection, access, rotation, and audit. You benefit from centralized key management and strict control over who can access private keys, when, and for how long.
All the above contribute to security best practices such as zero trust and zero standing privileges.
Let's switch the conversation to ephemeral SSH certificates. As we help our customers mature their privileged access security posture, they recognize the value SSH certificates provide to take a bigger bite out of risk and operational overhead.
No password is required. It's a positive step towards achieving passwordless nirvana. The SSH client and server exchange certificates instead of keys in a similar way (except in reverse) that your browser validates a host when you go to https://. The SSH certificate contains the public key and identity information for user validation by the SSH server. It includes other usage-specific details such as expiration date, the name of a server to log into, and permissions. An authority trusted for the specific use case digitally signs the certificate.
Your ops team no longer wastes vast amounts of time on mundane key management tasks. The overhead inherent in SSH key management—discovery, creation, protection, access, and rotation—is eliminated. As your *NIX estate scales, this benefit compounds. Instead of distributing public keys to servers for each user who needs access, only the public certificate of the CA is necessary to establish trust and enable verification of user SSH certificates presented at session initiation. Audit and compliance outcomes improve, your attack surface shrinks, and you avoid system inaccessibility due to key loss.
Since SSH certificates are temporary, they self-destruct, reducing the risks of compromise, sharing, and reuse. A compromised SSH private key could go unnoticed for some time. However, the ephemeral nature of SSH certificates invalidates the keypairs upon certificate expiration—typically a few seconds, sufficient to complete the authentication process.
SSH certificates are also easier to create and use. As we will see in the next section, having a PAM solution assume this responsibility drives more productivity benefits.
With Delinea’s Server PAM, you get the benefits outlined above, plus you are relieved from the administrative overhead of manual SSH certificate creation and key pair lifecycle management.
Delinea Server PAM generates SSH key pairs and mints SSH certificates on-demand using a built-in CA. When logged into Delinea Server PAM, an administrator can select a target system and request a login session by selecting "Use My Account."
Assuming the admin has the necessary permissions, Delinea PAM generates the SSH certificate and keypair, embeds the public key in the certificate, binds the certificate to the requesting user via certificate attributes, and signs the certificate with the CA's private key. The certificate is only valid for that specific user ID and target machine for a limited time.
Delinea Server PAM reaches out to the named server, relaying the certificate for validation. If valid, Delinea Server PAM queries PAM policies to confirm that the user is permitted to log in. If so, initiates the privileged SSO user session without further user interaction or ops team involvement. With a short-fuse expiration, the certificate is useless if shared or intercepted.
This streamlines access for internal admins and allays concerns over compromised SSH keys used by third-party vendors when combined with access workflows.
Since the key and certificate processing happens automatically behind the scenes, we can also sidestep several concerns over the general use of SSH certificates:
Let's finish with my list of best practices around using SSH for server access in modern enterprises.
In conclusion, you should avoid standard username and password-based SSH authentication. SSH key-based authentication improves some security aspects but introduces others, along with onerous SSH key management. SSH certificate-based access represents the best option and, when automated through PAM, is optimal for risk reduction and operational efficiency.