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 keys are authentication credentials Authorized keys define who can access each system Identity keys identify users and provide access Certificate-based user authentication Device authentication keys Host keys authenticate servers Known host keys Session keys How to configure key-based authentication How to set up public key authentication for OpenSSH Storing keys in ssh-agent for single sign-on Recommended key sizes Identity key location Authorized key location Moving SSH keys to a root-owned location OpenSSH's limitation on the number of private keys What do SSH keys look like How does authentication in SSH work? Public key authentication How common are SSH keys and what is the risk How to eliminate SSH keys entirely 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. 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. For more information, see the dedicated page on authorized keys. 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. For more information, see the dedicated page on identity keys. 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. 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 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. Key based authentication in SSH is called public key authentication. It is easy to configure by end users in the default configuration. On the other hand, security-conscious organizations need to establish clear policies for provisioning and terminating key-based access. SSH keys are typically configured in an authorized_keys file in 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 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 We recommend selecting key sizes according to NIST SP 800-57. The default key sizes used by the 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 The default identity key location can also be configured in /etc/ssh/ssh_config or the user's 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 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 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. In principle, moving SSH keys to a root-owned location is easy: Create a suitable root-owned directory, e.g., Create a subdirectory under this directory for each user, and move each user's Finally, change set 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 An authorized key can look like this: An identity key can look like this: 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, public key authentication, or other means. 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. The Zero Trust Suite by SSH can be used to eliminate SSH keys from servers entirely and establish policy-based access control and session logging across the enterprise. It also eliminates most of the administrative burden of managing keys, while still providing the benefits: automation and single sign-on.Contents
SSH keys are authentication credentials
Authorized keys define who can access each system
Identity keys identify users and provide access
Certificate-based user authentication
Device authentication keys
Host keys authenticate servers
Known host keys
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.Session keys
How to configure key-based authentication
How to set up public key authentication for OpenSSH
.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.Storing keys in ssh-agent for single sign-on
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.AllowAgentForwarding
to yes
in /etc/ssh/sshd_config on the server and ForwardAgent
to yes
in the client configuration file /etc/ssh/ssh_config.Recommended key sizes
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.Identity key location
.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..ssh/config
file using the IdentityFile
option.Authorized key location
AuthorizedKeysFile
option. The default is .ssh/authorized_keys
in the user's home directory.Moving SSH keys to a root-owned location
/etc/ssh/keys
, under which authorized keys are stored.authorized_keys
file to /etc/ssh/keys/<user>/authorized_keys
.AuthorizedKeysFile /etc/ssh/keys/%u/authorized_keys
in /etc/ssh/sshd_config
.OpenSSH's limitation on the number of private keys
.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.What do SSH keys look like
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBN+Mh3U/3We4VYtV1QmWUFIzFLTUeegl1Ao5/QGtCRGAZn8bxX9KlCrrWISIjSYAwCajIEGSPEZwPNMBoK8XD8Q= ylo@klar
-----BEGIN EC PRIVATE KEY----- MHcCAQEEIJWbvSW7h50HPwG+bWR3DXgQ6YhOxYbe0ifr1rRUvsUuoAoGCCqGSM49 AwEHoUQDQgAE34yHdT/dZ7hVi1XVCZZQUjMUtNR56CXUCjn9Aa0JEYBmfxvFf0qU KutYhIiNJgDAJqMgQZI8RnA80wGgrxcPxA== -----END EC PRIVATE KEY-----
How does authentication in SSH work?
Public key authentication
How common are SSH keys and what is the risk
How to eliminate SSH keys entirely
FAQs
What are the SSH key keys? ›
An SSH key is an access credential for the SSH (secure shell) network protocol. This authenticated and encrypted secure network protocol is used for remote communication between machines on an unsecured open network. SSH is used for remote file transfer, network management, and remote operating system access.
What is SSH key and why it is used? ›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.
What is an SSH key for dummies? ›An SSH key is a secure access credential used in the Secure Shell (SSH) protocol. SSH key pairs use public key infrastructure (PKI) technology, the gold standard for digital identity authentication and encryption, to provide a secure and scalable method of authentication.
What is an example of an SSH key? ›An example of an SSH key can be ssh-id-rsa This is an RSA key often stored in an SSH authorized_keys file. It is especially important for maintaining secure connections in Windows systems.
Do I need an SSH key? ›SSH key pairs offer a more secure way of logging into your server than a password that can easily be cracked with a dictionary and brute force attacks.
What is SSH used for? ›The Secure Shell (SSH) protocol is a method for securely sending commands to a computer over an unsecured network. SSH uses cryptography to authenticate and encrypt connections between devices.
Is an SSH key a password? ›SSH supports two main methods of authentication: passwords and keys. Passwords are easy to use and remember, but they are also vulnerable to brute-force attacks, phishing, and human errors. Keys are more secure and efficient, but they require more setup and management.
How do I use my SSH key? ›- Generate a private and public key, known as the key pair. ...
- Add the corresponding public key to the server.
- The server stores and marks the public key as approved.
- The server allows access to anyone who proves the ownership of the corresponding private key.
- Using the run command.
- Execute the following command. cat ~/.ssh/id_rsa.pub. The command will display your SSH key on your Linux machine without requiring your key authentication password.
We strongly recommend using only the ed25519 algorithm (an ECDSA variant). It is the most secure SSH key type widely available, and is very well supported in the majority of systems. If you are using an client or server without ed25519 support, you should consider upgrading where possible.
Does the SSH key include an email address? ›
1 Answer. SSH keys don't have an email address field. They have a comment field, which typically contains a "user@host" of the system which generated the key, but that's neither an email address nor something that SSH (much less Git) pays attention to – it's just a label for the key. No, GitHub doesn't do that.
How do I find out which SSH key is used? ›- Open Terminal .
- Enter ls -al ~/.ssh to see if existing SSH keys are present. $ ls -al ~/.ssh # Lists the files in your .ssh directory, if they exist.
- Check the directory listing to see if you already have a public SSH key. ...
- Either generate a new SSH key or upload an existing key.
- Open Terminal .
- Enter ls -al ~/.ssh to see if existing SSH keys are present. $ ls -al ~/.ssh # Lists the files in your .ssh directory, if they exist.
- Check the directory listing to see if you already have a public SSH key. ...
- Either generate a new SSH key or upload an existing key.
- Digital Signature Algorithm (DSA)
- Rivest-Shamir-Adleman (RSA)
- Elliptic Curve DSA (ECDSA)
- EdDSA and Ed25519.
By default, a key is named with an "id_" prefix, followed by the key type ("rsa", "dsa", "ed25519"), and the public key also has a ". pub" suffix. So a common example is id_rsa and id_rsa. pub .
How to list all keys in SSH? ›The command ssh-add -L lists all the public keys for all current SSH "identities". The first entry on each line is the key type, (ssh-rsa, ssh-dss, etc.), the second entry on each line is the public key itself, and the third entry on each line is typically the user and hostname on which the key was generated.