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 SSH keys are primarily used for automated processes and for implementing single sign-on by system administrators and power users.
SSH keys play a central role in securing and enabling modern information systems. They offer convenience and improved security. Even more importantly, they enable the automation that makes modern cloud services and other computer-dependent services possible and cost-effective.
SSH (Secure Shell) is used for managing networks, operating systems, and configurations. It is also used for transferring files and tunneling application data. Practically every data center in the world uses SSH. More than half of world's web servers are managed using SSH. Every Fortune 500 company uses it. I keeps the modern world running.
SSH keys have some unique properties as access credentials.
- They can be self-provisioned by users. Users can issue new credentials to themselves or to anyone else for access to the account they are logged into. It is possible to configure SSH so that users cannot self-provision, and this is usually done as part of SSH key management. In the default configuration, however, the widely used free OpenSSH allows all users to provision new credentials.
- They never expire. They have no timestamp and no validity period. They remain valid until removed from the system. 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. SSH keys, on the other hand, were a highly technical concept hidden in the system administrator domain until recently. As a result, most 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.
How Common Are SSH Keys?
SSH keys turn out to be extremely common and widely used. In one customer case, we examined 500 applications and 15,000 servers, and found 3 million authorized keys and 750,000 unique key pairs. The 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.
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 SSH keys.
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.
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, SSH keys generally affect provisions related to 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).
Some of the relevant compliance mandates include:
- Critical infrastructure - Cybersecurity Framework. US government includes the following in critical infrastructure: financial services, communications, healthcare, transportation, food supply, dams, key manufacturers, chemical facilities, and emergency services.
- Public companies - Sarbanes-Oxley law
- Anyone processing credit card payments - PCI DSS
- Banking - Basel III, COBIT, central bank regulations (e.g., US, Germany, Singapore, Hong Kong)
- Health care - HIPAA law & Security Rule
- Energy - PCI DSS
- US Federal Governmnt - FISMA law and NIST SP 800-53r4
- EU GDPR
- Many companies also care about ISO/IEC 27001:2013
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 need to be treated as part of identity governance or identity and access management.
Types of SSH Keys
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,
For more details, see the separate page on authorized keys.
An authorized key can look like this:
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar
Identity Keys - Private User Keys
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-----
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.
For more information, see the separate page on host keys.
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
Authentication using SSH keys 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
Power and Benefits of SSH Keys
The usefulness and benefits of SSH keys 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.
- 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 SSH keys allow centralized, automated, and process-driven control of trusted access. This is mandatory for organizations to gain compliance with the many regulatory mandates, such as PCI DSS, Sarbanes-Oxley law, and HIPAA law.