{"id":56170,"date":"2025-01-15T12:45:00","date_gmt":"2025-01-15T17:45:00","guid":{"rendered":"https:\/\/jumpcloud.com\/?p=56170"},"modified":"2025-01-28T15:16:46","modified_gmt":"2025-01-28T20:16:46","slug":"how-to-manage-ssh-keys-linux","status":"publish","type":"post","link":"https:\/\/jumpcloud.com\/blog\/how-to-manage-ssh-keys-linux","title":{"rendered":"How to Generate and Manage Linux SSH Keys"},"content":{"rendered":"\n

Jump to Tutorial<\/a><\/p>\n\n\n\n

Secure Shell, or Secure Socket Shell \u2014 commonly abbreviated as SSH \u2014 is a secure network protocol that allows users to securely authenticate to remote devices. SSH leverages a pair of SSH keys<\/a> to encrypt communication with a remote system. The key pair is cryptographic in nature and made up of a public<\/em> and private<\/em> key. The keys work in tandem to provide authentication between the client and the remote system. <\/p>\n\n\n\n

SSH keys grant users access to critical systems such as cloud and on-premise servers and network devices. Typically, these are systems that should only be accessed by authorized users, and no one else. Proper management of these keys is therefore essential to ensure that the SSH keys are in the right hands and used in accordance with the best security practices.<\/p>\n\n\n\n

Before we proceed further, let us draw a distinction between public and private keys.<\/p>\n\n\n\n

Private and Public SSH Keys<\/strong><\/h2>\n\n\n\n

As the name suggests, the private key is only meant for the person who created it, and therefore strictly resides on the client system. It allows users to securely authenticate with the remote server, and should always be kept secret and never disclosed to anyone. In the wrong hands, the private key could be compromised and malicious users can use it to breach your systems. We cannot emphasize this enough: the private key should never<\/em> be revealed to anyone else.<\/p>\n\n\n\n

On the other hand, the public key can be freely shared with any server you wish to connect to without compromising your identity. It is used for encrypting data exchanged between the server and the client. The private key decrypts the messages sent from the remote server and a connection is established. On the remote system, the public key is saved in the authorized_keys<\/kbd> <\/code>file.<\/p>\n\n\n\n

Let\u2019s now switch gears and check out how SSH authentication works. <\/p>\n\n\n\n

How SSH Authentication Works<\/strong><\/h2>\n\n\n\n

SSH authentication is broadly categorized into two types: password-based and public key authentication.<\/p>\n\n\n\n

1. Password-based authentication<\/h3>\n\n\n\n

In password-based authentication, the client sends an authentication request to the server which includes the encrypted username and password for the remote server. Upon receipt, the server decrypts the request and validates the credentials in plain text. Once verified, the client is notified of the authentication outcome.<\/p>\n\n\n\n

2. Public key authentication<\/h3>\n\n\n\n

Public key authentication \u2014 also known as asymmetric encryption \u2014 uses a cryptographic key pair which comprises a private and public key on the client system. After generating the SSH key pair, both the public and private keys are saved on the client. The client then copies the public key to the remote server. <\/p>\n\n\n\n

So, how does the authentication really work?\u00a0<\/p>\n\n\n\n

During authentication, the client system sends an authentication request to the remote server which includes a public key. The remote server then receives the request and checks if the public key matches the one copied to it. If the key is valid and matches the one on the server, the server then creates a secret message and encrypts it with the public key from the client. The message is then sent back to the client whereupon the private key decrypts the message. Because this is asymmetric encryption, only the client system can decrypt the message with the private key. Once the message is decrypted, the server acknowledges it and the authentication is successful.<\/p>\n\n\n\n

Public key authentication is the more preferred authentication of the two. It is more convenient and secure than password-based authentication \u2014 and for good reasons. SSH keys are complex and difficult to crack thanks to the strong encryption algorithms used. In addition, only the user with the private key can access the remote system. <\/p>\n\n\n\n

When public key authentication is enabled, password authentication should be turned off so that only the private key alone can be used to authenticate with the remote system.<\/p>\n\n\n\n

How to Generate an SSH Key Pair<\/strong> on Linux<\/h2>\n\n\n\n

To leverage public key authentication, the first step is to generate the SSH key pair. To do so, launch your terminal on the client and run the following command:<\/p>\n\n\n\n

$ ssh-keygen -t rsa<\/code><\/p>\n\n\n\n

The -t<\/kbd> flag specifies the type of the SSH key to be created. In this case, the RSA key pair. <\/p>\n\n\n\n

There are two possible values of RSA: \u201crsa1<\/kbd>\u201d for RSA version 1 and \u201crsa<\/kbd>\u201d for RSA version 2. Since the first option is now deprecated and considered weak, here we are going with the latter which is considerably stronger.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Save the SSH Key to a Location<\/h3>\n\n\n\n

Specify the location that you wish to save the key pair. Typically, the default path is the user\u2019s home directory or simply the <\/code>~\/.ssh<\/kbd> folder (for example, \/user\/home\/.ssh<\/kbd>). If you wish to save the keys in this location, simply press \u201cENTER.\u201d<\/p>\n\n\n\n

Next, you will be required to provide a passphrase (optional). This adds an extra layer of security in the rare event that a hacker gets a hold of the key. You can leave it blank or specify a key phrase that will be required on each login attempt. To leave it blank, just hit \u201cENTER.\u201d<\/p>\n\n\n\n

To confirm the keypair has been successfully generated, list the contents of the ~\/.ssh<\/kbd> <\/code>directory.<\/p>\n\n\n\n

$ ls -l ~\/.ssh<\/code><\/p>\n\n\n\n

The id_rsa<\/kbd> <\/code>is the private key which, as mentioned, should be kept top-secret on the client system to prevent potential compromise.<\/p>\n\n\n\n

The id_rsa.pub<\/kbd> <\/code>is the public key that can be freely shared with the server you intend to connect to.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Copy the Public Key to the Remote Server<\/h3>\n\n\n\n

Once the SSH keys are generated, the next step is to copy the public key to the remote server. You can achieve this using the simple ssh-copy-id<\/kbd> <\/code>command:<\/p>\n\n\n\n

$ ssh-copy-id username@remote-server-IP<\/code><\/p>\n\n\n\n

Provide the remote server\u2019s password and hit \u201cENTER\u201d to copy the public key. You should get an acknowledgment from the remote server that the key was successfully added. The public key is saved to the ~\/.ssh\/authorized_keys<\/kbd> <\/code>file on the remote system.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Log in with SSH Passwordless Authentication<\/h3>\n\n\n\n

The next time you attempt to log in, the SSH-key challenge response will take place and you will be automatically logged in without password authentication. This is what is popularly known as SSH passwordless authentication since authentication is fully reliant on the SSH-key pair.<\/p>\n\n\n\n

$ ssh remote-server-ip<\/code><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Troubleshooting Common Issues<\/h2>\n\n\n\n

Permission Denied Errors<\/h3>\n\n\n\n

Permission denied errors are one of the most common issues encountered when using SSH keys. These errors typically indicate a problem with file permissions or misconfigurations in the authorized_keys<\/kbd> file. Common causes and solutions entail:<\/strong><\/p>\n\n\n\n

    \n
  1. Incorrect File Permissions<\/strong>: SSH requires strict permissions on key files to ensure security.\n