SSH Key - The Forgotten Access Credential
An SSH key is an access credential in the SSH protocol. Its function is similar to that of user names and passwords, but the keys are primarily used for automated processes and for implementing single sign-on by system administrators and power users.
SSH (Secure Shell) is used for managing networks, operating systems, and configurations. It is also inside many file transfer tools and configuration management tools. Every major corporation uses it, in every data center.
The keys enable the automation that makes modern cloud services and other computer-dependent services possible and cost-effective. They offer convenience and improved security when properly managed.
How Common Are SSH Keys?
The keys turn out to be extremely common and widely used. A typical Fortune 500 enterprise has several million SSH keys granting access to their production servers. In one customer case, we examined 500 applications and 15,000 servers, and found 3,000,000 authorized keys and 750,000 unique key pairs. This organization also had over five million daily logins using keys. The keys were used for executing financial transactions, updating configurations, moving log data, file transfers, interactive logins by system administrators, and many other purposes.
It is turning out that most large enterprises have hundreds of thousands or even millions of keys. It is turning into a massive security and compliance problem.
Potential Risks and Remedies
A big risk with unmanaged SSH keys is uncontrolled attack spread, where hackers move laterally from server to server, data center to data center using the keys. The keys can potentially be used to kill a Fortune 500.
Combined with tunneling, the keys may be used to access internal servers from the Internet. It is also common to see them used to circumvent privileged access management systems.
SSH keys control who can access what. They must be included in identity and access management. They need provisioning and termination processes just like passwords, and legacy keys must be discovered, unused and policy-violating keys eliminated, and remaining keys documented and maintained according to a well-defined policy. Universal SSH Key Manager is designed to make this process smooth and efficient.
Laws and Regulations Mandate Management
All major compliance mandates require managing SSH key based access. They need governance, just like any other identities and credentials. Proper processes must be established for provisioning and termination and legacy keys need to be sorted out.
In compliance regulations, the keys are relevat to controls on provisioning and terminating access credentials, separation of duties (e.g., development -> production access), the principle of least privilege, configuration change management, and definition of internal boundaries (such as around PCI and financial data environments or classified compartments).
Secure Shell keys have some unique properties as access credentials.
- They can be self-provisioned by users in OpenSSH default configuration.
- They never expire. This is a big difference between SSH keys and PKI certificates - certificates typically have an expiration date.
User names and passwords have been part of identity and access management (IAM) programs in enterprises for decades. The keys were a highly technical concept hidden in the system administrator domain until fairly recently. As a result, many identity and access management professionals have not even been aware that such credentials exist and they have not been part of IAM or CISSP training.
Technically Cryptographic Keys, but Really Access Credentials
An SSH key is technically a cryptographic key. However, functionally they are access credentials. Sometimes SSH keys are lumped together with other encryption keys, but from a management perspective, they really need to be treated as part of identity governance or identity and access management. It's all about who can access what.
Types of Keys in SSH
SSH actually uses keys for multiple purposes that are described here.
Authorized Keys - Public User Keys
They are typically configured in an authorized_keys file in
.ssh subdirectory in the user's home directory. Typically a system administrator would install an authorized key on a server using the ssh-copy-id tool.
Identity keys are usually stored in a user's
.ssh directory, for example,
An authorized key can look like this:
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar
Identity Keys - Private User Keys
Identity keys are private keys that an SSH client uses to authenticate itself when logging into an SSH server.
Identity keys are usually created using the ssh-keygen program and stored in the
.ssh directory in the user's home directory. By default, identity key file names start with
id_<algorithm>, but other names are also often used. Identity keys may be password-protected, however the ones used for automated access usually are not. In most environments the vast majority of the keys are not protected by a passphrase.
For more information, see the separate page on identity keys.
An identity key can look like this:
-----BEGIN EC PRIVATE KEY----- MHcCAQEEIJWbvSW7h50HPwG+bWR3DXgQ6YhOxYbe0ifr1rRUvsUuoAoGCCqGSM49 AwEHoUQDQgAE34yHdT/dZ7hVi1XVCZZQUjMUtNR56CXUCjn9Aa0JEYBmfxvFf0qU KutYhIiNJgDAJqMgQZI8RnA80wGgrxcPxA== -----END EC PRIVATE KEY-----
Authorized keys and identity keys are jointly called user keys. They relate to user authentication, as opposed to host keys that are used for host authentication.
Host Keys - Public and Private
Host keys are used for authenticating hosts, i.e., computers. There are both public host keys and private host keys. Certificates can also be used for authenticating hosts. See the separate page on host keys for more information.
Known Host Keys
When an SSH client connects to a server, it tries to authenticate the server using its host key. The client may have a repository of known host keys, essentially associating host keys with host names. If the client knows the server's host key, it is able to validate that there is no man-in-the-middle attack on the connection.
On the first connection to a host, the client would typically not know its host key, and would by default just trust it. This facilitates the best possible compromise between security and ease of deployment. Better security may be obtained by using certificates.
A session key in SSH is an encryption key used for encrypting the bulk of the data in a connection. The session key is negotiated during the connection and then used with a symmetric encryption algorithm and a message authentication code algorithm to protect the data.
For more information, see the separate page on session keys.
How Does Authentication in SSH Work?
Initializing a connection in SSH consists of:
- Negotiating the version of the protocol to use
- Negotiating cryptographic algorithms and other options to use
- Negotiating a one-time session key for encrypting the rest of the session
- Authenticating the server host using its host key
- Authenticating the user using a password, identity key, or other means. For some authentication methods, the client host key might also be used as part of the authentication.
After this, data can be exchanged, including terminal data, graphical data, and files.
Public Key Authentication
The key-based authentication mechanism in SSH is called public key authentication. Essentially, some session-specific data is signed using the private identity key. The signature is then sent to the server that checks if the key used for signing is configured as an authorized key. The server then verifies the digital signature using the public key in the authorized key. The identity key is never sent to the server.
The essential thing in public key authentication is that it allows one server to access another server without having to type in a password. This powerful feature is why it is so widely used for file transfers (using the SFTP protocol) and configuration management.
Recommended Key Sizes
We recommend selecting key sizes according to NIST SP 800-57. The default key sizes used by the
ssh-keygen tool are generally of acceptable strength. In fact, since the protocol never reveals the private keys, the algorithms and keys used for the keys are not as critical as they are in, for example, PKI certificates.
Power and Benefits of Key-Based Authentication
The usefulness and benefits of key-based authentication become apparent when one considers that:
- Key-based authentication is considerably stronger than passwords could ever be. Even very long passwords contain much less entropy.
- A compromised server cannot steal the credential (the server never sees the private key).
- The keys allow automating secure access for file transfers and executing remote commands without the need of user interaction to type in a password or the need to hard-code the password to the script or application.
- With appropriate key management, the keys allow centralized, automated, and process-driven control of trusted access.