
How to secure Debian Server 9.X – Setup SSH keys
Introduction
SSH, or secure shell, is an encrypted protocol used to administer and communicate with servers. When working with a Debian 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 a Debian 9 installation. SSH keys provide an easy, secure way of logging into your server and are recommended for all users.
Step 1 – How is an SSH key used
I will first try to visualize the use of SSH keys a bit. Once a client is trying to get access to your server, the SSH service will check with what kind of authentication the client is coming in.
If password authentication is used, and the SSH service is configured to disallow this, the client will be rejected immediately. If the client is using a private key, the server will check if this matches with the public key on the server.
Please check the diagram below.

The first step is to create the SSH key(s). There are 2 possible ways you can do this:
- You create the private & public key on your server, then download the private key to your client PC.
- You create the public & private key on your client, and then insert it inside the server configuration.
I personally like to use the second version. The way to accomplish this is different per client (Linux/Windows/Mac) so let’s take a look at that now.
Step 2 – Creating the SSH key
Linux
If you are on a Linux client (Ubuntu, Debian etc.) you will have the ability to use a terminal and create your SSH key easily:
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). However, you would need a supercomputer to crack the 2048-bit RSA key.
After entering the command, you should see the following output:
1 2 |
Generating public/private rsa key pair. Enter file in which to save the key (/root/.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 had previously generated an SSH key pair, you may see the following prompt:
1 2 |
/root/.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.
You should then see the following prompt:
1 |
Enter passphrase (empty for no passphrase): |
Here you optionally may enter a secure passphrase, which is highly recommended. A passphrase adds an additional layer of security to prevent unauthorized users from logging in.
You should then see the following output:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: SHA256:MjFVnPNMVg1OW6dZQQEOHOGsv08oCAuPrPpM3lMsGzc root@debian-s-1vcpu-1gb-ams3-01 The key's randomart image is: +---[RSA 2048]----+ | .oo=oo***| | . *.=o *o| | o O .= | | o . o | | . oo S. | | . * Eo. . . | | .o O o . o . | | +..o . o | |oo+ .. ... | +----[SHA256]-----+ |
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.
Windows
Most of the users will have a Windows client to connect to your server. Since Windows doesn’t have the same terminal as Linux does, you will not be able to follow the steps above.
Therefor we will use a program called PuTTYgen to create our SSH keys. If you have downloaded Putty as an SSH client before, with the Windows installer, you will also have PuTTYgen.
First run PuTTYgen and click on Generate. The program will ask you to move your mouse randomly on the blank area, this way a random key will be generated.

Here you optionally may enter a secure passphrase and a comment, which is highly recommended. A passphrase adds an additional layer of security to prevent unauthorized users from logging in.
The comment can be used to distinguish your different keys if you have multiple.
Once done, you will have a public key output which we can use to secure our server.
Important: First of all save your private key somewhere safely! This will be used to authenticate to your server once we configured it.
Step 2 — Copy the Public Key to the Debian Server
The quickest way to copy your public key to the Debian 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 the alternate method provided in this section.
Copying Public Key Using ssh-copy-id (Linux Client)
The ssh-copy-id
tool is included by default in many operating systems, so you may have it available on your local system. For this method to work, you must already have password-based SSH access to your server.
To use the utility, you simply need to specify the remote host (Your server) that you would like to connect to and the user account that you have password SSH access to. This is the account to which your public SSH key will be copied.
The syntax is:
1 |
ssh-copy-id username@remote_host |
You may see the following message:
1 2 3 |
The authenticity of host '167.99.44.40 (167.99.44.40)' 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)? y |
This means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type “y” and press ENTER
to continue.
Next, the utility will scan your local account for the id_rsa.pub
key that we created earlier. When it finds the key, it will prompt you for the password of the remote user’s account:
1 2 3 |
/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@167.99.44.40's password: |
Type in the password of your server(your typing will not 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 see the following output:
1 |
Number of key(s) added: 1 |
Now try logging into the machine, with:
1 |
ssh username@167.99.44.40 |
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.
Copying Public Key Manually (Windows)
If you do not have a Linux client and not able to use the ssh-copy-id utility, you will have to copy the public key to your server manually.
We will manually append the content of your id_rsa.pub
file to the ~/.ssh/authorized_keys
file on your remote machine.
Since we already create our SSH keys with PuTTYgen, we can just use the output from this program, copy it, and place it into our remote server.
You will see the key’s content, which should look something like this:

You will have to copy the fully output (check the scroll wheel) of this public key. If you are not logged in yet, login to your remote server with the password authentication.
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 the file if necessary:
1 2 3 |
cat << EOT >> ~/.ssh/authorized_keys public_key_string EOT |
In the above command, substitute the public_key_string
with the public key output from PuTTYgen on your local PC so it will looke something like this:
1 2 3 |
cat << EOT >> ~/.ssh/authorized_keys ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAksIolUApjf3QXMtqijp3tpaE5GnARFyc1znfIBk1wYPCjRIDjQvLESDa7qd/m05Oxif3dWAB1iNSkENq8qqhTFlAt/nLg48p5dSf0oIzHmDTPxXnDqi6JCh3ROqzA9Aqj+e0Z6CbrQdOdhU15o+GDalx8HWY0L1lvPAFR+qjMblX2ihFzZOn08mr2bficuGh1YYqRiRHCjaH5XETg9sCm6CYCJC4nHc6XMN7/CAXInoXVnHHC9mCRhifC8YZFSHMGZFpQRPpQ9pk0m9p2HF3BIDpGTKQt8A0kvK4uvPS7uzMW40RxCw2gxF5Y9wo41miN/U8m5Noa86BxcAVph8fnQ== RSA key tutorial EOT |
Finally, we’ll 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 another user account, it’s also important that the ~/.ssh
directory belongs to the other user and not to root
:
1 |
chown -R sammy:sammy ~/.ssh |
In this tutorial our user is named sammy but you should substitute the appropriate username into the above command.
We can now attempt passwordless authentication with our Debian server.
Step 3 — Authenticate to Debian Server Using SSH Keys
If you have successfully completed one of the procedures above, you should be able to log into the remote host without the remote account’s password.
The basic process is the same (linux):
1 |
ssh username@remote_host |
On windows & using PuTTY, you will have to change some settings. First enter the hostname (IP) from the remote host again, put this time also use a private key. You can find this under:
Connection –> SSH –> Auth
And browse to your private key we created earlier.

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 now (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 Debian server.
If key-based authentication was successful, continue on to learn how to further secure your system by disabling password authentication.
Step 4 — Disable 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.
The next step will disable password-based logins, so 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. Uncomment the line and set the value to “no”. This will disable your ability to log in via SSH using plain passwords:
1 2 3 |
... PasswordAuthentication no ... |
Save and close the file when you are finished by pressing CTRL
+ X
, then Y
to confirm saving the file, and finally ENTER
to exit nano. To actually implement these changes, we 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:
Once you have verified your SSH service, you can safely close all current server sessions.
The SSH daemon on your Debian server now only responds to SSH keys. Password-based authentication has successfully 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 would like to know more about hardening your Linux server, check the next parts.
Share This Post
Recent Posts
- How to secure Debian Server 9.X – Scan for malicious items (Rkhunter)
- How to secure Debian Server 9.X – Setup a firewall
- How to secure Debian Server 9.X – Disable root login & change SSH port
- How to secure Debian Server 9.X – Setup SSH keys
- How to make a WordPress website running on a Linux webserver – Part 1
Leave a Reply