How To Authenticate Over SSH With Keys Instead of Passwords

Simon Slangen 15-07-2013

How To Authenticate Over SSH With Keys Instead of Passwords keySSH is a great way to gain remote access to your computer. Similar to FTP, you can connect over SSH FTP What SSH Is & How It's Different From FTP [Technology Explained] Read More to gain secure access to a file server with your favorite FTP client Master FTP File Transfers On All Of Your Sites With FileZilla A large number of FTP clients of old had hiccups when it came to large file transfers. The apps experienced the usual timeouts that you would expect when the computer sits there for 15 to... Read More , quickly accessing remote files, or even mounting a network disk to your computer. But there’s more to SSH than remote file access. Logging in over SSH in Terminal (or using PuTTY on Windows) gives you remote shell access (after all, SSH is short for Secure SHell). It’s how I manage my media server from a distance.


When you open the ports What Is Port Forwarding & How Can It Help Me? [MakeUseOf Explains] Do you cry a little inside when someone tells you there’s a port forwarding problem and that’s why your shiny new app won’t work? Your Xbox won’t let you play games, your torrent downloads refuse... Read More on your router (port 22 to be exact) you can not only access your SSH server from within your local network, but from anywhere in the world.

However, you don’t want to risk using a weak password for authentication. If anyone gains access to your computer over SSH, they gain complete shell access. Just to be clear, that’s not something we want. Luckily, it’s very easy to set up your global SSH server in a very secure manner by using key-based authentication and disabling password authentication on your server altogether.

Is This For Me?

It’s tempting to grow lax with personal security. If you’re using the server for private means, you might think that people simply don’t know about your server and hence won’t try to hack it — security through obscurity. That would be a very wrong assumption. Because (most) SSH traffic is transmitted on port 22, attackers routinely check the visibility of port 22 on random IP addresses, followed by a brute force attack. This is one of the ways botnets are made for use in DDOS attacks What Is a DDoS Attack? [MakeUseOf Explains] The term DDoS whistles past whenever cyber-activism rears up its head en-masse. These kind of attacks make international headlines because of multiple reasons. The issues that jumpstart those DDoS attacks are often controversial or highly... Read More .

To make a long story short: if you broadcast your SSH server over the internet (i.e. forward port 22), then yes, this is for you.

The Idea of Key-Based SSH Log-ins

Key-based SSH logins rely on the idea of public key cryptography. It would take us too far to explain the intricacies, but we’ll try to paint a simple picture of what is going on behind the scenes.


In the process below, your client computer generates two keys: a public key and a private key. The general idea is that you can encrypt data with the public key, but only decrypt it with the private key. We’ll put the public key on the server and ask it to encrypt all outgoing communication with it. This makes sure that only those clients with the private key can decrypt and read the data.

1. Install OpenSSH

First, we’re going to set up an SSH server using OpenSSH. If you already have an SSH server running and just want to know how to set up key-based authentication, you can skip this step. Use your favorite packet manager to install the OpenSSH server application. The simplest way might still be to run the apt-get command from the Terminal.

sudo apt-get install openssh-server

Enter your password, confirm and wait a minute for it to finish installing. Congratulations, you now have an SSH server. (That was easy!)



You can either use the application as-is, or edit /etc/ssh/sshd_config to configure it. Run the man sshd_config command in Terminal to get more information. Another great resource to learn more about OpenSSH is the relevant Ubuntu help page.

2. Generate Keys

We’ll generate a set of keys. Run the following commands (adapted from the OpenSSH/Keys Ubuntu Help page).

mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa

The first command creates a hidden directory ‘.ssh’ in your home folder, the second command changes the access permissions of the folder while the third command actually generates a set of RSA keys. You’ll first be asked for a location to save the keys (leave blank and press enter to save in the default location) and second for a passphrase.



This passphrase further encrypts the private key that’s stored on your computer, essentially giving you more time to secure the SSH server if your private key is ever stolen. Make sure you choose a passphrase you’re able to remember, as you’ll have to enter it when you try to use your key.

3. Transfer The Public Key

Next, you’ll need to transfer the public key you generated in the previous step to the SSH server computer. If your client machine also runs Linux, this can be achieved very easily by running the below command (substituting <username> and <host> for the username and IP address on your SSH server).

ssh-copy-id <username>@<host>

If your client doesn’t support the ssh-copy-id command, you can use the below command instead. It’s a bit more convoluted, but essentially achieves the same results.

cat ~/.ssh/ | ssh <username>@<host> "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

You’ll be asked to enter the user password for the SSH server. If the commands execute without errors, your public key will have been copied to the server.


4. Disable Password Authentication

Notice that your system still isn’t more secure than after step one. Although at least one client is configured to use key-based authentication, this still leaves room for other clients to connect with a password. To finish, we’ll disable password authentication altogether. After this step, only computers that have gone through the above process can connect to your SSH server.

To disable password authentication, edit the /etc/ssh/sshd_config file in your favorite editor. One of the easiest ways to edit a restricted file is, again, using Terminal. (I’m partial to nano, but you can use whatever you’re most comfortable with.)

sudo nano /etc/ssh/sshd_config

About 40 lines from the bottom of the file, you’ll find

#PasswordAuthentication yes

Remove the number sign (#) and change the setting to ‘no’, as below.

PasswordAuthentication no

The final file should look something like this:


Save the file by pressing CTRL+X. Confirm the edit and the filename, and you’re almost done. Just restart the SSH server to run it with these new settings.

sudo restart ssh

You’ll also notice that your client will stop asking for the passphrase to decrypt your key if password authentication is disabled on the server. Now that you have a secure SSH server, how do you intend to use it? As a secure file server, a remote shell, or to forward other services over SSH? Let us know in the comments section below!

Image credit: Shutterstock

Related topics: Online Security, Remote Access.

Affiliate Disclosure: By buying the products we recommend, you help keep the site alive. Read more.

Whatsapp Pinterest

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Ivar
    February 22, 2018 at 12:05 am

    "sudo restart ssh" was not a vaild command last time i checked ;)

  2. Aram Iskenderian
    July 19, 2013 at 1:12 am

    If you have a fairly modern/updated install of Linux (almost all of the new distros)It is as simple as

    1. At the computer/server you want to access from, run:
    Follow the on screen prompts
    If the keys were generated earlier you will be warned, if that's the case, you can skip this step.

    2. From the same computer/server, run:
    ssh-copy-id username@targetserver

    You will be prompted for the password. If provided properly and you did not see any error message, that will be the last time you are prompted for a password.

    To test, from the same computer/server run.
    ssh username@targetserver

    You should be logged in at the target server without any password prompts.

    • Simon Slangen
      August 11, 2013 at 7:24 pm

      Yep, that's similar what we did in steps 2 and 3. Thanks for sharing.

  3. jasray
    July 17, 2013 at 2:31 am

    It really helps, maybe more than anything else, that port 22 isn't used. Period. Not essential for a full and fast functioning SSH server.

    • Simon Slangen
      August 11, 2013 at 7:31 pm

      You're right, but most people will end up using a port from the higher ranges anyway. Forwarding low ports on your router can normally only be done through root.

  4. Lee
    July 15, 2013 at 2:21 am

    My college has an open source lab (which is neat because it's mostly student run, including the server room) and they use an interesting method to secure their servers. They have one server that is public-facing (for SSH anyway) and the rest aren't. To access the other servers, you have to SSH into the public server first and then use that to SSH into the other servers.

    I suppose it's not much use if someone figures out your password (and you use the same password for the public server as the private ones) but they would need to know the address of the private servers too.