What are SSH Keys?
Secure Socket Shell (SSH), also called Secure Shell, is a special network protocol leveraging public-key cryptography to enable authorized users to remotely access a computer or other device via access credentials called SSH keys. Because they are used to access sensitive resources and perform critical, highly privileged activities, it’s vital to properly manage SSH keys as you would other sensitive credentials.
While SSH keys are standard, and more frequently used, in Unix and Linux environments, they are also used in Windows systems. Read on for an overview of SSH key best practices covering SSH security and authentication, how SSH keys work, risks and benefits to consider with SSH keys, and how to manage SSH keys.
Overview of SSH Key Security Authentication
The Secure Shell, and the public-key cryptography (an encryption schema using two keys: one public, one private) SSH keys use, is designed to provide strong, encrypted verification and communication between the user and a remote computer.
SSH technology is based on the client-server model and provides an ideal way to access remote devices over unsecured networks, like the Internet. The technology is typically used by administrators for several functions including:
- Logging into remote computers/servers for support and maintenance
- Transferring files from computer to computer
- Remote execution of commands
- Offering support and updates
Today, Telnet, one of the Internet’s first remote login protocols and in use since the 1960’s, has largely been supplanted by SSH, owing to the latter protocol’s enhanced security features.
Keys, passwords, and certificates may all be used for SSH authentication. Of these approaches, SSH keys are the most universally accepted and used.
Like many other modern authentication systems, the next generation of SSH authorization solutions seems to be evolving around the use of certificates. This alternative approach iterates on the SSH key workflows, adding centralized key generation and revocation. Some challenges with this approach are that it is not supported by all SSH endpoints and requires other internal infrastructure, like Certificate Authorities and automated workflows, for access.
Types of SSH Keys
While many types of SSH keys (RSA, DSA, ECDSA, ed25519) exist, RSA remains the most common and provides the broadest system compatibility. The more modern elliptical curve variants of RSA keys are gaining in adoption.
Benefits of SSH Key Authentication
IT teams routinely use SSH keys to automate secure access to servers, bypassing the need to manually enter log-in credentials. The SSH network protocol encrypts all traffic between the client and the server while it is in transit. This means anyone eavesdropping on the traffic, such as by packet sniffing, would not be able to improperly access and decrypt transmitted data.
SSH is also resistant to brute force attacks and protects against certain attack vectors used to gain access to remote machines. Public key encryption ensures passwords need not be sent over the network, providing an additional layer of security. SSH keys are an excellent way to stay secure and compliant with various regulations and mandates, if you use best practice to generate, store, manage, and remove them.
Due to the massive number of SSH keys existing across an enterprise at any time, SSH key management software can significantly lower the overhead and risk of manually managing and updating keys.
Generating SSH Keys
SSH keys are always generated in pairs. These pairs consist of one “public” SSH key, and one “private” SSH key. These keys are paired using extremely strong algorithms, making it infeasible to guess or “fake” a private key, even if you know the public key. While private keys should be kept secret by the authorized person wishing to gain access to a system, public keys may be freely shared.
SSH keys are usually generated by a user entering a passphrase or other information. Typically, public and private keys will be generated from phrases of a few words.
SSH Key Access
A remote computer identifies itself to a user using its public key. When a user attempts to connect, the remote computer issues a “challenge” derived from the public key, for which only someone possessing the paired private key could correctly decrypt and respond. Once the challenge is correctly answered, the remote computer provides access.
In almost all cases, generating keys, sharing public keys, issuing challenges, answering them, and gaining access is managed by SSH software, so the process is largely transparent to the end user.
SSH Key Sprawl Poses Security & Operational Risk
SSH key sprawl exposes organizations to considerable cyber risk, especially considering they can provide such a high level of privileged access, such as root. In a study of over 400 IT security professionals conducted by Dimensional Research, over 90% of respondents reported they lacked a complete and accurate inventory of SSH keys. Additionally, nearly two out of three of the cybersecurity professionals stated they do not actively rotate SSH keys.
With typically 50 – 200 SSH keys per server, organizations may have upwards of a million SSH keys. While many SSH keys are long dormant and forgotten, just as with orphaned accounts, they can provide a backdoor for hackers to infiltrate critical servers. And once one server and SSH key is cracked, an attacker could move laterally and find more hidden keys. As with other types of privileged credentials (or passwords in general), when organizations rely on manual processes, there is a proclivity to reuse a passphrase across many SSH keys or to reuse the same public SSH key. This means one compromised key can then be harnessed to infiltrate multiple servers.
10 SSH Key Security Best Practices
As with any other security protocol, it’s imperative to implement SSH key security best practices and adhere to strong standards. NIST IR 7966 (Security of Interactive and Automated Access Management Using Secure Shell (SSH)) offers guidance for government organizations, businesses, and auditors on proper security controls for SSH implementations. NIST recommendations emphasize SSH key discovery, rotation, usage, and monitoring.
In even modestly complex environments, manual SSH key rotation is infeasible. For instance, you could identify accounts set up to use SSH keys, you could manually scan through authorized key files in the hidden .SSH user folder, but this falls short of helping you identify who has the private key matching any of the public keys in the file.
Organizations who recognize the risks posed by key sprawl and take a proactive cybersecurity posture typically use a dedicated SSH key management or automated privileged password management (PPM) solution to generate unique key pairs for each system, and perform frequent rotation. Automated solutions dramatically simplify the process of creating and rotating SSH keys, eliminating SSH key sprawl, and ensuring the keys enable productivity without compromising security.
To tighten security controls around SSH keys, you should also apply the following 10 best practices:
1. Discover all SSH Keys and Bring Under Active Management
A first step to eliminating SSH key sprawl and properly assessing SSH security risk is to discover and inventory all SSH keys, and then to reign in centralized control of all keys. This is also an appropriate juncture to audit and identify who is using various keys and how the keys are being used.
2. Change Default SSH Port
While on its own, security through obscurity is not a wholly sufficient protective posture, it is a simple step forward you can take in a broader defense-in-depth approach. Changing the default SSH port eliminates a surprising amount of basic discovery and attack vectors.
3. Disable SSH Root Login
The root account is a primary target on any *nix device, whether it be a physical, virtual, network, or IoT device. When it comes to hunting credentials, having the account name is half the battle. Eliminating the SSH root account from remote access substantially reduces your attack surface.
4. Implement Two-Factor Authentication
If you need to facilitate direct user to system access, with no other controls in place, a standard best practice access requirement is to add any 2FA step to the authentication workflow. This can include standards like TOTP or U2F, and usually includes the implementation of some local PAM module per endpoint.
5. Ensure SSH Key Attribution
Tie SSH keys back to an individual, rather than just to a shared account leveraged by multiple users. Clear attribution will provide an effective SSH audit trail and more direct oversight. This can be achieved with a thorough SSH key distribution for your user base, or a more centralized key management and audit solution that automates these functions.
6. Enforce Minimal Levels of User Rights Through PoLP
Apply the principle of least privilege (PoLP), such as in tying SSH keys to granular areas of remote devices, so users can only access certain, necessary systems. This limits the potential fallout from misuse of SSH keys.
7. Stay Attentive to SSH Key Rotation
Implement diligent SSH key rotation -- force users to generate keys on a regular basis and disallow use of the same passphrases across multiple accounts or iterations. These actions help protect the organization from password re-use attacks. In organizations with a large SSH key estate, this can only be feasibly performed via an automated solution.
SSH Keys may be one of the types of credentials embedded within code, such as in applications and files. This practice creates dangerous backdoors for malware and hackers to exploit. Hardcoded SSH keys with simple or default passphrases may be vulnerable to password-guessing attacks and other threats. Therefore, an important piece of SSH security is to uncover and eliminate embedded SSH keys, and bring them under centralized management.
9. Proxy SSH access
Direct, unfiltered TCP access to systems represents a key security threat. Some rudimentary solutions include reverse proxies or dumb traffic relays. Modern access management solutions enable highly controlled, audited access across the internet boundary. A sufficient proxy for SSH access not only facilitates access to the end system, but also supports privileged sessions through approval requests, access policies, credential ejection, and fully audited access for compliance and regulation requirements.
10. Audit All Privileged Session Activity
Any privileged session started via an SSH Key authentication (or other means) should be recorded and audited to meet both cybersecurity and regulatory needs. Privileged session management activities can entail capturing keystrokes and screens (allowing for live view and playback). Ideally, you also layer on the ability to control (pause or terminate) privileged sessions in real-time to maintain strong oversight and a short leash over privileged activity.
Matt Miller, Director, Content Marketing & SEO
Matt Miller is Director, Content Marketing at BeyondTrust. Prior to BeyondTrust, he developed and executed marketing strategies on cybersecurity, cloud technologies, and data governance in roles at Accelerite (a business unit of Persistent Systems), WatchGuard Technologies, and Microsoft. Earlier in his career Matt held various roles in IR, marketing, and corporate communications in the biotech / biopharmaceutical industry. His experience and interests traverse cybersecurity, cloud / virtualization, IoT, economics, information governance, and risk management. He is also an avid homebrewer (working toward his Black Belt in beer) and writer.