What is SSH?
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.
- SSH – Secure Shell protocol
This is a network-layer client-server protocol that enables computers to communicate securely. It was designed for synchronous activities, i.e., a user (or batch file) at one end making requests to a remote system and waiting for a response before moving on to the next request. - SSH – Clients
As with all client-server protocols, you need client and server applications that speak the language. Several popular SSH clients exist, including:
- SSH: Secure shell. The SSH client creates an interactive login shell to the target system using an ID, a password or SSH key. Think of it like a remote console. The user types in shell commands that get executed on the remote machine. In the Windows world, this is somewhat analogous to PowerShell remote.
- SFTP: Secure file transfer protocol. This client performs several operations on remote files, such as listing, copying, moving, deleting, and transferring files, with the ability to pause and resume transfers. Again, an ID, password, or SSH key is used to authenticate to the target server.
- SCP: Secure copy. This is like sftp, except you use it only for transferring (copying) files, and it is non-interactive. It is typically command-line; you type the "scp" command at the OS prompt along with all necessary parameters.
- SSH: Secure shell. The SSH client creates an interactive login shell to the target system using an ID, a password or SSH key. Think of it like a remote console. The user types in shell commands that get executed on the remote machine. In the Windows world, this is somewhat analogous to PowerShell remote.
What are the different methods of SSH authentication?
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.
- Passwords: The most common method. The user provides an ID and password at the start of the session. The target system verifies the credential and, if valid, establishes the login session.
- SSH keys: More secure than passwords, relying on cryptographic strength. The user creates a public/private key pair (e.g., via the ssh-keygen command). They keep the private key safe on their laptop and add the public key to the local account on the server they wish to access.
For example, to log in to the "tony" account, you’d add the public key to the ~/tony/.ssh/authorized_keys file. This authorizes the private key as a credential to log in as "tony," granting access to the server without requiring a password. - SSH certificates: This method avoids installing public keys on each server. An SSH certificate is a file that associates the SSH public key with information about the user's identity and other options relevant to the use of the public key it contains.
For example, the user ID to log in with, the target system hostname, the certificate lifetime, and the signature of an approving certificate authority (CA). Instead of persisting on disk like SSH keys, SSH certificates are temporary—they auto-expire. The SSH Server obtains the user public key in the certificate during session initiation and uses it to validate the user.
What problem are/were we trying to solve with SSH?
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.
SSH key management challenges
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.
Try Our Free IT Tools
SSH Keys + Privileged Access Management—"Vault and Takeover"
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.
Delinea Secret Server SSH Key General Screen 
- SSH key discovery ensures you have complete visibility and are alerted to unsanctioned SSH key creation.
- The vault can rotate key pairs automatically to reduce the window of opportunity for a threat actor. Key pair rotation can be scheduled, on-demand, or triggered by an action such as a Secret check-in operation. Users who need server access must obtain it through the vault, so you can enforce Role Based Access Controls (RBAC) and audit all activity.
- RBAC at the vault limits who has access to vaulted SSH private keys. An HSM can optionally protect these keys for stronger hardware-based protection.
- Approval workflows allow users (employees and vendors) to request access Just-in-Time (JIT) for a limited time.
- When accessing vaulted SSH secrets, Multi-Factor Authentication (MFA) adds additional identity assurance and contributes to stopping human adversaries, bots, and malware.
- Delinea Secret Server governs session management, transparently creating SSH key-based login sessions without revealing the private key, averting reuse and sharing.
- With audit logs, reports, and session recordings, you can prove that essential security controls are in place and operational and improve incident response outcomes.
All the above contribute to security best practices such as zero trust and zero standing privileges.
Ephemeral SSH certificate benefits
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.
SSH Certificates + Privileged Access Management—"Search and Destroy "
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:
- Eliminate the need for PKI expertise to install, configure, and use SSH certificates.
- Eliminate the need for PKI infrastructure, such as a CA necessary to mint SSH certificates and keypairs.
- Even if you outlaw SSH key-based authentication in favor of SSH certificates, you rely on admins to comply by deleting their SSH keys on all servers and not generating new SSH keys. You can force this, however, by disabling SSH key-based authentication in the sshd_config file.
Top 8 best practices for SSH keys and SSH certificates
Let's finish with my list of best practices around using SSH for server access in modern enterprises.
- Automate SSH keypair discovery for continuous visibility and to react quickly to shadow SSH keys created by well-meaning admins or adversaries establishing backdoors.
- If you continue to use SSH key-based access (or if in transition to certificate-based), you must continuously scan for new SSH key pairs, vault discovered SSH key pairs, strictly control access, and rotate key pairs routinely.
- Disable SSH root login to servers and enforce least privilege access (see below).
- Deploy a PAM proxy as the only trusted source of SSH connections to server endpoints. You can then ensure that all SSH sessions originate from the trusted PAM platform where RBAC, MFA, and JIT access request workflows contribute to ensuring user validity and access legitimacy.
- Audit all activity for reporting, with session recording for visual analysis.
- Mitigate static SSH key risk and operational SSH key management overhead with an ephemeral SSH certificate-based model. Leverage a modern PAM to automatically mint SSH certificates that bind SSH keys to a specific user for strong accountability, audit, and reporting.
- Combine SSH certificates with PAM best practices such as zero trust and least privilege. Ensure admins log in with their enterprise account that has minimum rights. Deploy server-level PAM controls that enforce centralized PAM privilege elevation policies.
- Combine least privilege with SSH certificates to ensure accountability and minimize risk.
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.
IT security should be easy. We'll show you how
