Professional Documents
Culture Documents
COM
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.
Contents
SSH 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.
Functionally SSH keys resemble passwords. They grant access and control who can access what. In identity
and access management, they need similar policies, provisioning, and termination as user accounts and
passwords. One cannot have confidentiality, integrity, or any guarantees of continued availability of systems
without controlling SSH keys.
Technically the keys are cryptographic keys using a public key cryptosystem. However, functionally they are
authentication credentials and need to be managed as such.
Authorized keys are public keys that grant access. They are analogous to locks that the corresponding private
key can open.
Identity keys are private keys that an SSH client uses to authenticate itself when logging into an SSH server.
They are analogous to physical keys that can open one or more locks.
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.
PKI certificates can also be used for authentication. In this case, the user still has a private key but also has a
certificate associated with the key. The technology is supported in both Tectia SSH and OpenSSH, with some
differences. For more information, see the dedicated page on certificate-based authentication in SSH.
https://www.ssh.com/ssh/key/ 2/7
5/18/2018 Configure SSH key based secure authentication | SSH.COM
Host keys are used for authenticating hosts, i.e., computers. Their purpose is to prevent man-in-the-middle
attacks. See the separate page on host keys for more information.
Certificate-based host authentication can be a very attractive alternative in large organizations. It allows
device authentication keys to be rotated and managed conveniently and every connection to be secured.
One of the unique features of SSH is that by default, it trusts and remembers the host's key when first
connecting to it. This was a key differentiator that allowed SSH to be deployed grass-roots, as there was no
centralized key infrastructure for hosts in 1995, and still isn't today (2017), with exemption of SSL certificates
for web servers. The resulting ease of deployment was one of the main reasons SSH became successful.
The memorized host keys are called known host keys and they are stored in a file called known_hosts in
OpenSSH. As long as host keys don't change, this appoach is very easy to use and provides fairly good
security. However, in large organization and when the keys change, maintaining known hosts files can
become very time-consuming. Using certificates for host keys is recommended in that case. Tectia SSH
supports standard X.509 certificates for hosts. OpenSSH has its own proprietary certificate format. The
advantage of standard-based certificates is that they can be issued by any certificate authority (CA),
whereas no reliable CAs exist for OpenSSH keys. See the dedicated page on certificates with SSH for more
information.
SESSION 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.
SSH keys are typically configured in an authorized_keys file in .ssh subdirectory in the user's home directory.
Typically a system administrator would first create a key using ssh-keygen and then install it as an authorized
key on a server using the ssh-copy-id tool. See also the dedicated page on configuring authorized keys for
OpenSSH.
We recommend using passphrases for all identity keys used for interactive access. In principle we recommend
using passphrases for automated access as well, but this is often not practical.
SSH comes with a program called ssh-agent, which can hold user's decrypted private keys in memory and
use them to authenticate logins. The agent can also be used to access keys on a smartcard or in a Hardware
Security Module (HSM). See the documentation for ssh-agent on how to set it up.
The connection to the SSH agent can be forwarded to a server, so that single sign-on also works from that
server onwards. That feature should be used with care, as it allows a compromised server to use the user's
credentials from the original agent. Agent forwarding can, however, be a major convenience feature for
power users in less security critical environments.
To enable agent forwarding, set AllowAgentForwarding to yes in /etc/ssh/sshd_config on the server and
ForwardAgent to yes in the client configuration file /etc/ssh/ssh_config.
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 public keys that
are acceptable for user authentication, the algorithms used for the keys are not as critical as they are in, for
example, PKI certificates.
For RSA keys, 2048 bits is probably a good choice today (2017). However, many cryptographers now
recommend switching to ECDSA keys and think that advances in factoring large integers may make RSA keys
vulnerable in the near/mid-term. For ECDSA we recommend using 521 bit (sic!) keys, even though 384 or even
256 bit keys probably would be safe. There is just no practical benefit from using smaller keys.
Identity keys are usually stored in a user's .ssh directory, for example, .ssh/ssh_id_rsa. The default identity
key file name starts with id_<algorithm>. However, it is possible to specify any file name and any location
when creating a private key, and provide the path name with the -i option to the SSH client. For example, ssh
-i /home/ylo/secure/my-key ec2-user@awshost.domain.my would use a private key from the file my-key
for authentication.
The default identity key location can also be configured in /etc/ssh/ssh_config or the user's .ssh/config file
using the IdentityFile option.
When a user tries to log in using key-based authentication, the OpenSSH server looks for authorized keys
from a directory specifies in the server configuration using the AuthorizedKeysFile option. The default is
.ssh/authorized_keys in the user's home directory.
However, having the authorized keys stored in the user's home directory means that the user can add new
keys that authorize logins to his/her account. This is convenient, but the user can then give these keys to
friends or colleagues, or even sell them for Bitcoins (this has actually happened). SSH keys are furthermore
permanent and remain valid until expressly removed.
If authorized keys are added for root or service accounts, they easily remain valid even after the person who
installed them has left the organization. They are also a convenient way for hackers to establish permanent
https://www.ssh.com/ssh/key/ 4/7
5/18/2018 Configure SSH key based secure authentication | SSH.COM
presence on a system if there is no detection and alerts about unauthorized new keys.
For these reasons, most larger organizations want to move authorized keys to a root-owned location and
established a controlled provisioning and termination process for them.
1. Create a suitable root-owned directory, e.g., /etc/ssh/keys, under which authorized keys are stored.
2. Create a subdirectory under this directory for each user, and move each user's authorized_keys file
to /etc/ssh/keys/<user>/authorized_keys.
3. Finally, change set AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys in
/etc/ssh/sshd_config.
In practice, however, this is not always so simple, especially in larger environments. User names may come
from directories (e.g., Active Directory or LDAP). Many organizations have varying OpenSSH versions,
including very old systems or custom SSH builds that have non-standard built-in paths. We recommend using
key management tools such as Universal SSH Key Manager to hide this complexity in larger environments.
These tools can also implement a provisioning, termination, and approval workflow for keys and alerts about
unauthorized changes made by root users.
The OpenSSH server has a feature (I would call it a bug) that it counts testing whether a particular key can be
used for authentication as an authentication attempt. This has the consequence that if the user has more
than five keys in .ssh, only some of them work. This often causes key-based authentication to fail and is often
difficult for users to figure out. The way around this is to explicitly specify the private key to use using the -i
option. An alternative is to adjust the MaxAuthTries session on the server, but this is not a full solution and it is
undesirable to increase the number of attempts for password authentication.
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4V
YtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar
https://www.ssh.com/ssh/key/ 5/7
5/18/2018 Configure SSH key based secure authentication | SSH.COM
After this, data can be exchanged, including terminal data, graphics, and files.
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. It is also commonly used by system administrators for single sign-
on.
SSH keys turn out to be extremely common and widely used. Many large organizations have accumulated
them for twenty years without any controls. A typical Fortune 500 enterprise has several million keys granting
access to their 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. These keys
are access that is unaccounted for, and may risk the entire enterprise.
Copyright © 2017 SSH Communications Security, Inc. All Rights Reserved. See Service Terms and Privacy
Policy.
https://www.ssh.com/ssh/key/ 7/7