Working with SSH Key Pairs

Understand how public and private keys enable secure, passwordless SSH authentication.

To use key authentication, you must first have a key pair: a public key and a corresponding private key. You can either use an existing key pair or generate a new one. Typically, you only generate an SSH key pair one time and only change the key pair if it might have been compromised or when using a key to access systems with different encryption standards. Not all key pairs are compatible with OpenSSH and you might need to convert keys as required. For example, keys generated with the PuTTY SSH client aren't directly compatible with OpenSSH and might need to be converted before use. See the client software documentation if you're unsure about key format.

After you have obtained a key pair, copy the public key to any server to which you want to connect. Then to connect to the server, provide the matching private key. You can store the private key on a single client that you use to access the servers. For security, avoid copying the private key to several locations.

When generating key pairs, you can either configure them to have a password or not. Key pairs that don't have passphrases can help with scripted automation as they can access remote systems instantly so you won't need to enter the passphrase each time you connect. However, using a key without a passphrase can be poor security practice. Instead, you can use SSH Agent to remember a key passphrase for the entire login session.

Consider using SSH Agent Forwarding to connect between trusted systems, or use the ProxyJump command option where you might need to connect to another system through an untrusted or heavily shared bastion host.

Create new SSH key pairs with ssh-keygen and choose algorithms and locations.

Use the ssh-keygen command to generate a public and private authentication key pair. Authentication keys enable you to connect to a remote system without needing to supply a password each time that you connect. Each user must generate their own pair of keys.

ssh-keygen

ls -l $HOME/.ssh

...
-rw-------. 1 guest guest 1743 Apr 13 12:07 id_sshkey
-rw-r--r--. 1 guest guest  397 Apr 13 12:07 id_sshkey.pub
...

Configure key-based authentication so automated connections can proceed without a passphrase.

You can create a key pair that doesn't require a passphrase, which is useful for scripted environments where a tool might need SSH access to a remote system but shouldn't prompt for a passphrase.

For general use, and as a better practice, set a passphrase on the private key and then to use the SSH Agent to remember key passphrases for the entire login session. See Using the SSH Key Agent to Remember Passphrases for more information.

However, using the SSH Agent isn't always practical and for some services that are loaded at boot time you might need to create a key that doesn't use a passphrase.

To use OpenSSH utilities to access a remote system without supplying a password each time that you connect:

1. Use ssh-keygen to generate a public and private key pair, for example:

   ssh-keygen

   The command output is similar to the following sample output.

   ...
   Enter file in which to save the key (/home/user/.ssh/id_sshkey): <Enter>
   Created directory '/home/user/.ssh'.
   Enter passphrase (empty for no passphrase): <Enter>
   Enter same passphrase again: <Enter>
   ...

   Press Enter at each passphrase prompt.

2. Copy the public key to the remote server. See Copy the public key to the remote server.

3. If the usernames are different on the client and the server systems, create a $HOME/.ssh/config file entry for this connection. See Setting SSH Client Configuration Options for a Host.

4. Validate that permissions for the $HOME/.ssh configuration files are correct on both the server and client side. See Validating Configuration Permissions for more information.

5. To access the remote system without supplying a password, use ssh to sign in to the remote system to verify that the $HOME/.ssh/authorized_keys file contains only the keys for the systems from which you expect to connect, for example:

   ssh remote_user@host

If the key file is named in a nonstandard way, you can specify which key file to use by using the -i option when you connect:

ssh -i $HOME/.ssh/my_private_key remote_user@host

For more information, see the ssh-copy-id(1), ssh-keygen(1), and ssh_config(5) manual pages.

Add your public key to remote hosts using ssh-copy-id or manual updates.

Add the public key to the remote server file at $HOME/.ssh/authorized_keys. Various approaches are available for setting up the contents of this file. You can run ssh-copy-id or manually configure the file, as shown in the following sections.

Store authorized SSH keys in centralized identity services managed by SSSD.

If you need to manage many users across different systems, you might consider centralizing the storage of the authorized keys. Maintaining a single central resource for authorized_keys makes it easier to perform administration tasks, for example revoking old keys or adding new keys for sets of servers.

A common approach would be to configure the SSH server to use the System Security Services Daemon to access keys stored in a central location such as an LDAP or Identity Management (IPA) service. To configure user authentication against these services, see one of the following links:

• Oracle Linux 8: Setting Up System Users and Authentication

• Oracle Linux 9: Setting Up System Users and Authentication

• Oracle Linux 10: Setting Up System Users and Authentication

OpenSSH provides a tool to use SSSD to maintain and automatically update a separate cache of public keys when authenticating users. The sss_ssh_authorizedkeys command is responsible for retrieving a user's public key from the user entries in an Identity Management (IPA) domain. After the key is retrieved, the key is stored in the $HOME/.ssh/sss_authorized_keys, in the standard authorized keys format.

To configure the SSH server to use SSSD to retrieve public keys for users, edit /etc/ssh/sshd_config and verify that the following entries are present:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

After you edit the server configuration, restart the service:

sudo systemctl restart sshd

SSSD must already be configured and running and the keys must be stored appropriately so that SSH can use the service.

See the sss_ssh_authorizedkeys(1) manual page for more information.

Manage host key fingerprints in $HOME/.ssh/known_hosts to verify server identity.

Whenever you connect to a remote host, the SSH server on the remote host provides a public key. You can use this key to validate that you're connecting to the same host in the future to prevent man-in-the-middle (MITM) attacks. On the server side, this public key is stored as part of the HostKey pair. On the client system, the known_hosts database stores the public key for the host in the file $HOME/.ssh/known_hosts.

SSH Host key fingerprints from remote systems

When you connect to a remote system and the known_hosts database doesn't contain a key, the client prompts you to accept the fingerprint for the key. For example:

The authenticity of host 'server1.example.com (198.51.100.172)' can't be established.
ED25519 key fingerprint is SHA256:i45KP8BeY5c6nO87hjUrqo1fXsGgQkCpA5dHchXBWbk.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

If you accept the fingerprint, the $HOME/.ssh/known_hosts file stores the public key on the client system and you're no longer prompted every time you connect.

Listing key fingerprints in local known_hosts

You can list the fingerprints for keys stored in the known_hosts database by running:

ssh-keygen -l -f $HOME/.ssh/known_hosts

StrictHostKeyChecking

If the OpenSSH client has the StrictHostKeyChecking option set by default and the public key returned by the server changes, you're unable to connect to the remote server and a warning is displayed:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The ED25519 host key for server1.example.com has changed,
and the key for the corresponding IP address 198.51.100.172
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/user/.ssh/known_hosts:20
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:qMBpuwP/LXLV8F5awaYtbXHO8v7LrqyY2BwVZk7tDxY.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:125
ED25519 host key for server1.example.com has changed and you have requested strict checking.
Host key verification failed.

Host keys don't change, so when you see this warning, you might not be connecting to the same system that you have connected to before. However, the key can be different for a legitimate reason, such as if the remote system is reinstalled, the OpenSSH Server keys are regenerated, or the domain name entry or IP address is reassigned to a new system. In such cases, you might want to remove any existing record of the system in the known_hosts database.

Removing an existing key

If you're certain that you can trust a new key provided by a remote server, you can remove an existing key from the known_hosts database by running:

ssh-keygen -R server1.example.com

Disabling StrictHostKeyChecking

In test environments, where servers are constantly reinstalled or replaced, you might want to disable StrictHostKeyChecking for particular hosts. You can disable host key checking when you connect to a remote system as follows:

ssh -o StrictHostKeyChecking=no user@server1.example.com

If you need to constantly disable strict host checking, consider adding this option to a host entry in the client configuration. See Setting SSH Client Configuration Options for a Host for more information.

Strict host key checking is enabled by default to prevent man-in-the-middle (MITM) attacks, so disabling that functionality isn't considered good security practice and isn't recommended on production systems.

Apply best practices for securing, storing, and using SSH key pairs.

Follow these guidelines so that you can manage and use SSH key pairs to connect to remote hosts securely on the network.

• Set a strong passphrase when you generate the SSH key pair.

  For more information, see Generating Key Pairs Using the ssh-keygen Command.

• Verify the SSH key agent to avoid needing to type in the passphrase at every login.

  For more information, see Using the SSH Key Agent to Remember Passphrases.

• Restrict access for any SSH key pair that doesn't have a passphrase and is only used for scripting purposes.

  For more information, see Restricting SSH Key Access to Specific Commands.

• Don't share the private key with anyone else. Each member of the team must have their own SSH key pair so that the system administrator can control access to network resources.

• Don't copy the private key, or forward the SSH agent, to any other machine, remote servers, or cloud instances.

  For more information, see Copying Public Keys to Remote Servers.

• Don't store a copy of the private key on a bastion or jump host.

  For more information, see Using ProxyJump for Access Through a Jump Host.