SSH Key - The Forgotten Access Credential
An SSH key is a cryptographic key used for authentication in the SSH protocol. SSH keys grant access, similar to user names and passwords.
SSH keys play a central role in securing and enabling modern information systems. They offer convenience and improved security for system administrators and sophisticated users. Even more importantly, they enable the automation that makes modern cloud services and other computer-dependent services possible.
SSH 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. The 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.
SSH keys can expose an organization to massive security risks if not properly managed. They grant access, just like user names and passwords, often to privileged accounts. They are also being used by malware and hackers for spreading attacks. Combined with tunneling, they can be used to gain access to the internal corporate network from the public Internet.
SSH keys relate to managing identities and access, provisioning and termination of access, separation of duties, the principle of least privilege, configuration change management, boundary definition and protection, separation of test and development systems from production, privileged access, etc.
Furthermore, SSH relates to many other compliance requirements, such as those relating to remote access, data-in-transit encryption, session recording, audit and forensics, boundary protection, data leakage prevention, anti-virus/anti-malware protection, and others.
- RSA is a well-known, widely published algorithm. It was the first algorithm supported by SSH version 1.0.
- DSA (Digital Signature Algorithm) is a US Government standard described in NIST FIPS Publication 186-4.
- ECDSA (Elliptic Curve Digital Signature Algorithm) is another US Government standard algorithm, also described in NIST FIPS Publication 186-4.
- ed25519 (an Edwards-Curve Digital Signature Algorithm) is a fast public key algorithm.
SSH keys do have an associated key size and algorithm. While key size and algorithm are relevant policy issues in an enterprise, from a real security standpoint they are not particularly critical in the context of SSH. The initial protocol version, SSH 1.0, already generated 1024-bit RSA keys by default, and the protocol never reveals authentication keys from the server to the client, so the attacker cannot even start trying to factor the key. Checking key sizes and updating to longer keys or more modern algorithms is recommended as part of key management. However, changing the keys is usually postponed to later stages in the project. All keys must have been discovered before starting to change the keys, or otherwise major outages could result from keys that were not properly changed everywhere.
The keys can also have certificates associated with them. Tectia SSH supports standards-compliant X.509 certificates, whereas OpenSSH uses a proprietary certificate format. Certificates may be used in SSH for both host authentication and user authentication.
The Public Key Authentication Mechanism in SSH
SSH introduced a new authentication mechanism, called public key authentication as an alternative to ssh password authentication. The basic idea is that a client sends its public key and a digital signature of certain session-specific data to the server. The server then verifies that the key belongs to the client and that the signature is correct. The server may use
known_hosts files or certificates for verifying that the key belongs to the server.
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.