Advance

Ways To Set Up SSH Keys on Debian 10

Ways To Set Up SSH Keys on Debian 10
0
(0)

SSH or Secure shell is an encrypted protocol that is used to administer and communicate with servers. As you are learning to work with SSH on the server of  Debian 10, you will find yourself spending all your time in a terminal session connected to your server through SSH. Due to our last articles about SSH tutorials, you may have been familiar with this subject.

 

 

 

Ways To Set Up SSH Keys on Debian 10

Let’s walk through the steps of this guide to show you how easy and secure you can Set Up SSH Keys on Debian 10. And log into your server with SSH keys. Except for these features, it is recommended for all users.

 

Recommended Article: How to install Apache Tomcat on Windows

 

Step 1: How To Create the RSA Key Pair

First, let’s create a key pair on the client machine.

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

Note 1: The routine effect of ssh-keygen is to create a 2048-bit RSA key pair. With this, you can make sure of the security. Also, consider that you may optionally pass in the -b 4096 flags to create a larger 4096-bit key.

Note 2: Do not forget to replace your considered name or email in the prompted lines of commands.

Now, you need to save the key pair into the .ssh/ subdirectory in your home directory or specify an alternate path. To do this, press enter.

You may have generated an SSH key pair already. If yes, you will see the following prompt:

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

Very Important: At this point, please be aware that if you select yes, you will not be able to reverse it. So, choose to overwrite the key on disk whenever you are all sure. Because after that you can not authenticate using the previous key anymore.

Then, you will see an output like the below.

Output
Enter passphrase (empty for no passphrase):

Now, you may enter a secure passphrase(optionally). By this, you see passphrase adds an additional layer of security to prevent unauthorized users from logging in. In case you are interested in learning more about security, read our guide on Tutorial Configure SSH Key-Based Authentication on a Linux Server.

Then, you will see the below output:

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=++.            |  +-----------------+

Therefore, you have a public and private key that you can use to authenticate. Now, try to place the public key on your server so that you can use SSH-key-based authentication to log in.

Step 2: How To Copy the Public Key to Debian Server

Let’s see what could be the quickest way to copy your public key to the Debian host. You can use a utility called ssh-copy-id. Here is a simple method which is really recommended. If you do not have an ssh-copy-id available to you on your client machine. In the following, you see two alternate methods provided in this section.

 

How To Copy Public Key Using ssh-copy-id

You may have the ssh-copy-id tool on your local system, as it is available in many operating systems by default. To let this method work, the password-based SSH should be accessible.

The best way of using the utility is to specify the remote host which you choose to connect to and the user account that you have password SSH access to. As you guess, this is the account to which your public SSH key will be copied.

Here is the considered command:

ssh-copy-id username@remote_host

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

The above output says you that your local computer does not recognize the remote host. Because it is the first time you connect to a new host. As always type yes” and press ENTER to continue.

After that, the utility will scan your local account for the id_rsa.pub key that you created earlier. You will prompt for r the password of the remote user’s account when it finds the key.

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  [email protected]'s password:

Now, type in the password and press ENTER. So using the password you provided, the utility will connect to the account on the remote host. After that, 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.

Now, you see an output like the below:

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

Now, you can make sure that your id_rsa.pub key has been uploaded to the remote account.

 

 

How to Copy Public Key Using SSH

You can upload your keys using a conventional SSH method in a condition which you do not have ssh-copy-id available, but you have password-based SSH access to an account on your server.

Using the cat command, you can do this and let it read the contents of the public SSH key on your local computer and piping that through an SSH connection to the remote server.

Also, you can make sure of existing the ~/.ssh directory and to have the correct permissions under the account you are using.

Therefore, you can then output the content we piped over into a file called authorized_keys within this directory. You can use the >> redirect symbol to append the content instead of overwriting it. With this, you can add keys without destroying previously added keys.

The full command looks like as the below:

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

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

By receiving this output you can see that your local computer does not recognize the remote host. As always type “yes” and press ENTER to continue.

In the following, you will be prompted to enter the remote user account password:

Output
[email protected]'s password:

Once you enter your password, the content of your id_rsa.pub key will be copied to the end of the authorized_keys file of the remote user’s account.

 

How To Copy Public Key Manually

Try to complete the above process manually, if you do not have password-based SSH access to your server available.

Appending the content of your id_rsa.pub file to the ~/.ssh/authorized_keys file on your remote machine will be done manually.

Now, type the following command into your local computer to display the content of your id_rsa.pub key.

cat ~/.ssh/id_rsa.pub
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

Try to access your remote host and after that make sure of existing the ~/.ssh directory. Using the following command will create the directory if necessary, or do nothing if it already exists.

mkdir -p ~/.ssh

It is time to modify the authorized_keys file within this directory. Also, you can add the contents of your id_rsa.pub file to the end of the authorized_keys file.

echo public_key_string >> ~/.ssh/authorized_keys

In the above 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….

Finally, type the below command to make sure that the ~/.ssh directory and authorized_keys file have the appropriate permissions set:

chmod -R go= ~/.ssh

Using this command causes removing all “group” and “other” permissions for the ~/.ssh/ directory.

Please consider that in case you are 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:

chown -R noodi:noodi ~/.ssh

As you guess, our user in this guide is named noodi but you should substitute the appropriate username into the above command.

At this point, you can attempt passwordless authentication with your Debian server. In case you need to verify how it would be for CentOS 8, trace our article on Tutorial set up SSH Keys on CentOS 8

 

Step 3: How to Authenticate to Debian Server Using SSH Keys

If all recent steps have been successfully completed, you should be able to log into the remote host without the remote account’s password.

ssh username@remote_host

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

Point: You see the above output when this is your first time connecting to this host.

Also, it says you that your local computer does not recognize the remote host. Type “yes” and then press ENTER to continue.

Therefore, you will be logged in immediately, if you did not supply a passphrase for your private key. Then you will be prompted to enter it now if you supplied a passphrase for the private key when you created the key. After all, you will see a new shell session should open for you with the configured account on the Debian server when the is authenticating finished.

You are free to continue on to learn how to further secure your system by disabling password authentication if key-based authentication was successful.

 

Recommended Article: Ways To Set Up SSH Keys on Debian 10

 

Step 4: How To Disable Password Authentication on your Server

In this step, you can log into your account using SSH without a password, just if you have successfully configured SSH-key-based authentication to your account. But please notice that although your password-based authentication mechanism is still active, your server is still exposed to brute-force attacks.

Check if you 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.

From now on, you would see how it will lock down password-based logins, so ensuring that you will still be able to get administrative access is crucial.

Log into your remote server with SSH keys, when you confirmed that your remote account has administrative privileges. And it is possible either as root or with an account with sudo privileges. Then, open up the SSH daemon’s configuration file:

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 account passwords:

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

Now, you can save and close the file when you finished. You can do this by pressing CTRL + X, then Y to confirm saving the file, and finally ENTER to exit nano.

To restart the sshd service and implement these changes:

sudo systemctl restart ssh

To consider more for security, open up a new terminal window and test that the SSH service is functioning correctly before closing this session:

ssh username@remote_host

Next, you can close all current server sessions when you verified your SSH service. And be aware that the SSH daemon on your Debian server now only responds to SSH keys. Password-based authentication has successfully been disabled.

 

conclusion

You have passed the four steps of this guide and learned how to Set Up SSH Keys on Debian 10. You may also be interested in getting more information about SSH on other servers. we recommend you to have a look at How to set up SSH keys on Ubuntu 20.04. However, from now on you have SSH-key-based authentication configured on your server, allowing you to sign in without providing an account password.

How useful was this post?

Click on a star to rate it!

Average rating 0 / 5. Vote count: 0

No votes so far! Be the first to rate this post.

View More Posts
Marilyn Bisson
Content Writer
Eldernode Writer
We Are Waiting for your valuable comments and you can be sure that it will be answered in the shortest possible time.

20 thoughts on “Ways To Set Up SSH Keys on Debian 10

    1. while you are in your terminal, enter ls -al ~/.ssh. And check your directory listing to see have you had any public SSH key or not.

    1. Although, SSH uses strong encryption and you are recommended to set your SSH client to act as a socks proxy, but an SSH tunnel does not offer all the benefits of a VPN.

    1. since, each SSH key includes 2 keys; anyone with a copy of the public key can encrypt data. Of course it can only be read by the person who holds the corresponding private key.

    1. In case you have checked the correction of permissions for the authorized_keys file and the private key, have a look at key-based authentication to be allowed by the server.

    1. I guess you are using sudo. Do not use it when cloning, pushing or pulling because the ssh-agent runs on the user level, not the root level. Otherwise, send me a message gain to verify more

    1. If you faced this message, your computer may have been unable to reach Bitbucket, likely due to something in your own network. So, contact to your network administrator to resolve the issue.

Leave a Reply

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

We are by your side every step of the way

Think about developing your online business; We will protect it compassionately

We are by your side every step of the way

+8595670151

7 days a week, 24 hours a day