Tutorial

How to Set Up SSH Keys on Ubuntu 18.04

Updated on April 6, 2022
author

Hanif Jetha

English
How to Set Up SSH Keys on Ubuntu 18.04
Not using Ubuntu 18.04?Choose a different version or distribution.
Ubuntu 18.04

Introduction

SSH, or secure shell, is an encrypted protocol used to administer and communicate with servers. When working with an Ubuntu server, chances are you will spend most of your time in a terminal session connected to your server through SSH.

In this guide, we’ll focus on setting up SSH keys for an Ubuntu 18.04 installation. SSH keys provide a secure way of logging into your server and are recommended for all users.

Step 1 — Creating the RSA Key Pair

The first step is to create a key pair on the client machine (usually your local computer):

  1. ssh-keygen

By default ssh-keygen will create a 2048-bit RSA key pair, which is secure enough for most use cases (you may optionally pass in the -b 4096 flag to create a larger 4096-bit key).

After entering the command, you should receive the following output:

Output
Generating public/private rsa key pair. Enter file in which to save the key (/your_home/.ssh/id_rsa):

Press ENTER to save the key pair into the .ssh/ subdirectory in your home directory, or specify an alternate path.

If you’ve previously generated an SSH key pair, you may receive the following prompt:

Output
/home/your_home/.ssh/id_rsa already exists. Overwrite (y/n)?

If you choose to overwrite the key on disk, you will not be able to authenticate using the previous key anymore. Be very careful when selecting yes, as this is a destructive process that cannot be reversed.

The next prompt will ask you to enter a secure passphrase:

Output
Enter passphrase (empty for no passphrase):

Here you have the option to enter a secure passphrase, which is highly recommended. A passphrase adds a layer of security to prevent unauthorized users from logging in. To learn more about security, consult our tutorial on How To Configure SSH Key-Based Authentication on a Linux Server.

All together, the ssh-keygen command will return output like the following:

Output
Your identification has been saved in /your_home/.ssh/id_rsa. Your public key has been saved in /your_home/.ssh/id_rsa.pub. The key fingerprint is: a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host The key's randomart image is: +--[ RSA 2048]----+ | ..o | | E o= . | | o. o | | .. | | ..S | | o o. | | =o.+. | |. =++.. | |o=++. | +-----------------+

You now have a public and private key that you can use to authenticate. The next step is to place the public key on your server so that you can use SSH-key-based authentication to log in.

Step 2 — Copying the Public Key to Ubuntu Server

The quickest way to copy your public key to the Ubuntu host is to use a utility called ssh-copy-id. Due to its simplicity, this method is highly recommended if available. If you do not have ssh-copy-id available to you on your client machine, you may use one of the two alternate methods provided in this section (copying via password-based SSH, or manually copying the key).

Copying Public Key Using ssh-copy-id

The ssh-copy-id tool is included by default in many operating systems, so you may have it available on your local system.

Note: For this method to work, you must already have password-based SSH access to your server.

To use the utility, you specify the remote host that you would like to connect to, and the user account that you have password-based SSH access to. This is the account to which your public SSH key will be copied.

The syntax is the following:

  1. ssh-copy-id username@remote_host

You may receive the following message:

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

This means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Write “yes” and press ENTER to continue.

Next, the utility will scan your local account for the id_rsa.pub key that you created earlier. When it finds the key, it will prompt you for the password of the remote user’s account:

Output
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys username@203.0.113.1's password:

Write in the password (nothing will be displayed for security purposes) and press ENTER. The utility will connect to the account on the remote host using the password you provided. It will then copy the contents of your ~/.ssh/id_rsa.pub key into a file in the remote account’s home ~/.ssh directory called authorized_keys.

You should receive the following output:

Output
Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'username@203.0.113.1'" and check to make sure that only the key(s) you wanted were added.

At this point, your id_rsa.pub key has been uploaded to the remote account. You can continue on to Step 3.

Copying Public Key Using SSH

If you do not have ssh-copy-id available, but you have password-based SSH access to an account on your server, you can upload your keys using a conventional SSH method. Remember, this will only work if you have password-based SSH access to your server.

You can do this by using the cat command to read the contents of the public SSH key on your local computer and piping that through an SSH connection to the remote server.

On the other side, you can make sure that the ~/.ssh directory exists and has the correct permissions under the account you’re using.

You can then output the content you piped over into a file called authorized_keys within this directory. Use the >> redirect symbol to append the content instead of overwriting it. This will let you add keys without destroying previously added keys.

The full command displays as the following:

  1. cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

You may receive the following message:

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

This means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Write “yes” and press ENTER to continue.

After, you should be prompted to enter the remote user account’s password:

Output
username@203.0.113.1's password:

After entering your password, the contents of your id_rsa.pub key will be copied to the end of the authorized_keys file of the remote user’s account. Continue on to Step 3 if this was successful.

Copying Public Key Manually

If you do not have password-based SSH access to your server available, you will have to complete the process manually.

This section outlines how to manually append the content of your id_rsa.pub file to the ~/.ssh/authorized_keys file on your remote machine.

To display the contents of your id_rsa.pub run the following command on your local computer:

  1. cat ~/.ssh/id_rsa.pub

This will return the key’s content in the command’s output:

Output
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

Access your remote host using whichever method you have available.

Once you have access to your account on the remote server, you should make sure the ~/.ssh directory exists. This command will create the directory if necessary, or do nothing if it already exists:

  1. mkdir -p ~/.ssh

Now you can create or modify the authorized_keys file within this directory. You can add the contents of your id_rsa.pub file to the end of the authorized_keys file, creating it if necessary. For this command, substitute the public_key_string with the output from the cat ~/.ssh/id_rsa.pub command that you executed on your local system. It should start with ssh-rsa AAAA...:

  1. echo public_key_string >> ~/.ssh/authorized_keys

Finally, ensure that the ~/.ssh directory and authorized_keys file have the appropriate permissions set:

  1. chmod -R go= ~/.ssh

This recursively removes all “group” and “other” permissions for the ~/.ssh/ directory.

If you’re using the root account to set up keys for a user account, it’s also important that the ~/.ssh directory belongs to the user and not to root. In this tutorial our user is named sammy but you should substitute the appropriate username into the following command:

  1. chown -R sammy:sammy ~/.ssh

Now you can attempt passwordless authentication with your Ubuntu server.

Step 3 — Authenticating to Ubuntu Server Using SSH Keys

If you’ve successfully completed one of the procedures in Step 2, you should be able to log into the remote host without the remote account’s password.

The process is the same:

  1. ssh username@remote_host

If this is your first time connecting to this host (if you used the manual method), you may receive something like this:

Output
The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

This means that your local computer does not recognize the remote host. Write “yes” and then press ENTER to continue.

If you did not supply a passphrase for your private key, you will be logged in immediately. If you supplied a passphrase for the private key when you created the key, you will be prompted to enter it (note that your keystrokes will not display in the terminal session for security). After authenticating, a new shell session should open for you with the configured account on the Ubuntu server.

If key-based authentication was successful, continue on to learn how to further secure your system by disabling password authentication.

Step 4 — Disabling Password Authentication on your Server

If you were able to log into your account using SSH without a password, you have successfully configured SSH-key-based authentication to your account. However, your password-based authentication mechanism is still active, meaning that your server is still exposed to brute-force attacks.

Before completing the steps in this section, make sure that you either have SSH-key-based authentication configured for the root account on this server, or preferably, that you have SSH-key-based authentication configured for a non-root account on this server with sudo privileges. This step will lock down password-based logins, ensuring that you will still be able to get administrative access is crucial.

Once you’ve confirmed that your remote account has administrative privileges, log into your remote server with SSH keys, either as root or with an account with sudo privileges. Then, open up the SSH daemon’s configuration file:

  1. sudo nano /etc/ssh/sshd_config

Inside the file, search for a directive called PasswordAuthentication. This may be commented out with a # at the beginning of the line. Uncomment the line by removing the #, and set the value to no. This will disable your ability to log in via SSH using account passwords:

/etc/ssh/sshd_config
...
PasswordAuthentication no
...

Save and close the file when you’re finished by pressing CTRL + X, then Y and ENTER to exit nano. To activate these changes, you need to restart the sshd service:

  1. sudo systemctl restart ssh

As a precaution, open up a new terminal window and test that the SSH service is functioning correctly before closing the current session:

  1. ssh username@remote_host

Once you’ve verified that your SSH service is functioning properly, you can safely close all current server sessions.

The SSH daemon on your Ubuntu server now only responds to SSH-key-based authentication and password-based authentication has been disabled.

Conclusion

You should now have SSH-key-based authentication configured on your server, allowing you to sign in without providing an account password.

If you’d like to learn more about working with SSH, take a look at our SSH Essentials Guide.

We’ve made it super easy to add SSH Keys to your new or existing DigitalOcean virtual machines.

Learn more here

About the authors
Default avatar
Hanif Jetha

author

Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?
 
7 Comments
Leave a comment...

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Fantastic tutorial. I was able to follow the instructions and connect to the server using the key-based authentication. One thing though, is this supposed to work for only one client machine? I used ssh-copy-id without any trouble. I try to follow the same process using a different laptop and i can’t connect to the server since it is now asking for a key. I changed the sshd config to allow password authentication but it appears it now defaults to key-based authentication and i’m unable to use ssh-copy-id from the 2nd client (since it doesn’t have they key yet). Should be a looking at another process for setting up the 2nd client? I really hope i don’t have to manually copy the key…

Hanif Jetha
DigitalOcean Employee
DigitalOcean Employee badge
July 20, 2018

Thank you for your feedback. You have a couple of options here for adding the second client’s public key. You can re-enable password authentication by reversing the steps in Step 4, and then proceed using any of the methods outlined in the guide (ssh-copy-id is quickest), or log in to your server using the first client, and copy the key in manually using the last method in Step 2.

Hope this is helpful!!

Thanks for this.

Don’t we have to save the private key somewhere?

alexdo
Site Moderator
Site Moderator badge
January 11, 2024

Yes, you should keep the private key secure and not share it with anyone. The private key is a sensitive piece of information that grants access to the associated SSH account.

When you generate an SSH key pair, typically consisting of a private key and a public key, you store the private key on your local machine, and the public key is copied to the remote server.

@hjet I’m just digging my way through the manual, there might be further commentaries, yet here we go.

ssh-copy-id username@remote_host

nope.no. no way. more like:

 ssh-copy-id -i 666 ***.***.**.xx                                
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "666.pub"                         
The authenticity of host 'xxx.xxx.xx.xx (xxx.xxx.xx.xx)' can't be established.                  
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx                    
Are you sure you want to continue connecting (yes/no)? yes                                      
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed                                                                              
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to 
install the new keys                                                                            
ak666@xxx.xxx.xx.xx's password:                                                                 
                                                                                                
Number of key(s) added: 1                                                                       
                                                                                                
Now try logging into the machine, with:   "ssh 'xxx.xxx.xx.xx'"                                 
and check to make sure that only the key(s) you wanted were added.                              
                                                                       

The correct syntax I happened to learn here, however, quite some time was wasted to brute-force the correct flags.

Please edit that code block, trifles like that demotivate a lot.

And thanks for the man, since it is truly monumental :)

alexdo
Site Moderator
Site Moderator badge
February 26, 2024

Here’s what you can try to resolve this issue:

  1. Check Public Key: Ensure that the public key (666.pub) you’re trying to copy is correct and matches the one generated on your local machine. You can verify the content of the public key file using a text editor or by running:
  1. cat 666.pub

Compare the content of this file with the content of the public key generated on your local machine.

  1. Retry ssh-copy-id Command: Try running the ssh-copy-id command again without the -i option, providing only the username and remote host:
  1. ssh-copy-id username@remote_host

This should prompt you for the password of the remote user (username) and copy your SSH public key to the appropriate location on the remote host.

  1. Manual Copy: If ssh-copy-id still doesn’t work, you can manually copy the content of your local public key (666.pub) and paste it into the ~/.ssh/authorized_keys file on the remote host. You can use a text editor on the remote host or the echo command to append the public key content to the authorized_keys file.
  1. echo "content_of_666.pub" >> ~/.ssh/authorized_keys

Replace content_of_666.pub with the actual content of your local public key.

  1. Verify SSH Access: After copying the public key, try SSH-ing into the remote host to ensure that key-based authentication is working correctly:
  1. ssh username@remote_host

Regards

I’m sticking with manual copy key ( accidentally lost my private key in my local machine :( ). But when i copy-paste my new public key into the default terminal in the digital ocean, this content copy just not the same as mine in local machine. I guess i must type every single character in that pub key. Does any one have any suggestions?

alexdo
Site Moderator
Site Moderator badge
February 26, 2024

The Copy/Paste functionality of our web console is a bit odd; the code backing it is custom due to the way the VNC window is implemented for accessing your Droplet. It isn’t a good idea, in my experience, to rely on the console for long copy/pasting like an SSH key.

My recommended method to get the key on the Droplet is over SSH itself. You can refer to the below articles:

https://docs.digitalocean.com/products/droplets/how-to/connect-with-ssh/ https://docs.digitalocean.com/products/droplets/how-to/connect-with-ssh/openssh/ https://docs.digitalocean.com/products/droplets/how-to/connect-with-ssh/putty/

You can enable PasswordAuthentication for your Droplet by modifying your /etc/ssh/sshd_config file. Once set to Yes restart the SSH service and connect via an SSH client for a more stable connection. You can then modify your ~/.ssh/authorized_keys file to add the appropriate public key.

This should do the job for you as well.

The other option is to temporary enable the PasswordAuthentication from no to yes in order to access your droplet using password and then once you’ve entered your key to disable the PasswordAuthentication again. This way is considered more secure than uploading the key to a Dropbox in case you don’t have any other server to us.

  1. Log in to the console on the DigitalOcean website.
  2. Type sudo nano /etc/ssh/sshd_config
  3. Change PasswordAuthentication from “no” to “yes” and save the file
  4. Open a terminal on your computer and type ssh username@[hostname or IP address] or if on a Windows box use PuTTY for password login making sure authentication parameters aren’t pointing to a private key
  5. Login with a password
  6. Type sudo nano ~/.ssh/authorized_keys
  7. Paste public key text here and save the file
  8. Type sudo nano /etc/ssh/sshd_config
  9. Change PasswordAuthentication from “yes” to “no” and save the file
  10. Log out and attempt to log back in (if using PuTTY make sure you set up auth parameters to point to your private key)

Hope that this helps!

Beware of Step 2 if you are using the manual method to add your SSH key—the paste function has problems with the DO console.

alexdo
Site Moderator
Site Moderator badge
February 26, 2024

Heya,

The recovery console is not intended for copy-paste commands indeed. It is most commonly used to regain access in emergency cases where access with normal ssh-agent is not available.

Regards

I have done till 2nd step successfully and following 3rd step. When i tried to login, it says login incorrect.

How i did that? I opened console and tried this command with sudo and without sudo after login: ssh root@remote-host and then entered password.

thanks

KFSys
Site Moderator
Site Moderator badge
October 23, 2024

You need to run ssh (the client, and possibly the server) with more verbosity to understand why authentication is failing. For the client, run

ssh -vvv username@host

On the server end, check the logs. /var/log/auth.log will give you a pretty good idea about what happens when you try to login, look for messages that contain sshd. There are a variety of reasons why authentication could be failing, ranging from simple (you aren’t using the right username) to more complicated (sshd is configured to use the wrong authentication system).

Step 1: Run ssh-add on the client machine to add the SSH key to the agent in order to avoid an error.

sign_and_send_pubkey: signing failed: agent refused operation

alexdo
Site Moderator
Site Moderator badge
February 26, 2024

Heya,

The error message sign_and_send_pubkey: signing failed agent refused operation indicates that the SSH agent is refusing to perform the operation of signing the public key.

Here are a few steps you can take to troubleshoot and resolve this issue:

  1. Check SSH Agent Status: First, verify that the SSH agent is running on your client machine. You can do this by running the following command:
  1. eval "$(ssh-agent -s)"

This command starts the SSH agent if it’s not already running and sets up the necessary environment variables.

  1. Ensure SSH Agent is Loaded with Keys: Confirm that your SSH key is added to the SSH agent. You can list the identities (keys) currently loaded into the SSH agent using the following command:
  1. ssh-add -l

If your key is not listed, you’ll need to add it using ssh-add:

  1. ssh-add /path/to/your/private/key

Replace /path/to/your/private/key with the actual path to your private SSH key.

  1. Verify Agent Forwarding: If you’re connecting to a remote server that requires agent forwarding, ensure that agent forwarding is enabled in your SSH configuration (~/.ssh/config):
  1. Host your_remote_server ForwardAgent yes

This allows the SSH agent on your local machine to forward authentication requests to the remote server.

  1. Check SSH Agent Configuration: Sometimes, the SSH agent configuration might cause issues. Check the configuration file (~/.ssh/config) for any misconfigurations or conflicting settings.

  2. Restart SSH Agent: If you’re still encountering issues, you can try restarting the SSH agent:

  1. eval "$(ssh-agent -s)"

Then, add your SSH key again using ssh-add.

  1. Update SSH Key Permissions: Ensure that the permissions on your SSH key files (id_rsa and id_rsa.pub) are set correctly. The private key (id_rsa) should have permissions set to 600 (chmod 600 ~/.ssh/id_rsa).

After trying these steps, attempt to add your SSH key to the agent again using ssh-add.

If you continue to experience issues, please provide more details, and I’ll be happy to assist you further.

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up

Join the Tech Talk
Success! Thank you! Please check your email for further details.

Please complete your information!

Become a contributor for community

Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

DigitalOcean Documentation

Full documentation for every DigitalOcean product.

Resources for startups and SMBs

The Wave has everything you need to know about building a business, from raising funding to marketing your product.

Get our newsletter

Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.

New accounts only. By submitting your email you agree to our Privacy Policy

The developer cloud

Scale up as you grow — whether you're running one virtual machine or ten thousand.

Get started for free

Sign up and get $200 in credit for your first 60 days with DigitalOcean.*

*This promotional offer applies to new accounts only.