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

While there are a few different ways of logging into an SSH server, in this guide, we’ll focus on setting up SSH keys. SSH keys provide an easy, yet extremely secure way of logging into your server. For this reason, this is the method we recommend for all users.

How Do SSH Keys Work?

An SSH server can authenticate clients using a variety of different methods. The most basic of these is password authentication, which is easy to use, but not the most secure.

Although passwords are sent to the server in a secure manner, they are generally not complex or long enough to be resistant to repeated, persistent attackers. Modern processing power combined with automated scripts make brute forcing a password-protected account very possible. Although there are other methods of adding additional security (fail2ban, etc.), SSH keys prove to be a reliable and secure alternative.

SSH key pairs are two cryptographically secure keys that can be used to authenticate a client to an SSH server. Each key pair consists of a public key and a private key.

The private key is retained by the client and should be kept absolutely secret. Any compromise of the private key will allow the attacker to log into servers that are configured with the associated public key without additional authentication. As an additional precaution, the key can be encrypted on disk with a passphrase.

The associated public key can be shared freely without any negative consequences. The public key can be used to encrypt messages that only the private key can decrypt. This property is employed as a way of authenticating using the key pair.

The public key is uploaded to a remote server that you want to be able to log into with SSH. The key is added to a special file within the user account you will be logging into called ~/.ssh/authorized_keys.

When a client attempts to authenticate using SSH keys, the server can test the client on whether they are in possession of the private key. If the client can prove that it owns the private key, a shell session is spawned or the requested command is executed.

How To Create SSH Keys

The first step to configure SSH key authentication to your server is to generate an SSH key pair on your local computer.

To do this, we can use a special utility called ssh-keygen, which is included with the standard OpenSSH suite of tools. By default, this will create a 2048 bit RSA key pair, which is fine for most uses.

On your local computer, generate a SSH key pair by typing:

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

The utility will prompt you to select a location for the keys that will be generated. By default, the keys will be stored in the ~/.ssh directory within your user’s home directory. The private key will be called id_rsa and the associated public key will be called

Usually, it is best to stick with the default location at this stage. Doing so will allow your SSH client to automatically find your SSH keys when attempting to authenticate. If you would like to choose a non-standard path, type that in now, otherwise, press ENTER to accept the default.

If you had previously generated an SSH key pair, you may see a prompt that looks like this:

/home/username/.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.

Created directory '/home/username/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again: 

Next, you will be prompted to enter a passphrase for the key. This is an optional passphrase that can be used to encrypt the private key file on disk.

You may be wondering what advantages an SSH key provides if you still need to enter a passphrase. Some of the advantages are:

  • The private SSH key (the part that can be passphrase protected), is never exposed on the network. The passphrase is only used to decrypt the key on the local machine. This means that network-based brute forcing will not be possible against the passphrase.
  • The private key is kept within a restricted directory. The SSH client will not recognize private keys that are not kept in restricted directories. The key itself must also have restricted permissions (read and write only available for the owner). This means that other users on the system cannot snoop.
  • Any attacker hoping to crack the private SSH key passphrase must already have access to the system. This means that they will already have access to your user account or the root account. If you are in this position, the passphrase can prevent the attacker from immediately logging into your other servers. This will hopefully give you time to create and implement a new SSH key pair and remove access from the compromised key.

Since the private key is never exposed to the network and is protected through file permissions, this file should never be accessible to anyone other than you (and the root user). The passphrase serves as an additional layer of protection in case these conditions are compromised.

A passphrase is an optional addition. If you enter one, you will have to provide it every time you use this key (unless you are running SSH agent software that stores the decrypted key). We recommend using a passphrase, but if you do not want to set a passphrase, you can simply press ENTER to bypass this prompt.

Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/
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 authentication to log in.

How to Embed your Public Key when Creating your Server

If you are starting up a new DigitalOcean server, you can automatically embed your SSH public key in your new server’s root account.

Towards the bottom of the Droplet creation page, there is an option to add SSH keys to your server:

SSH key embed

If you have already added a public key file to your DigitalOcean account, you will see it here as a selectable option (there are two existing keys in the example above: “Work key” and “Home key”). To embed an existing key, simply click on it and it will highlight. You can embed multiple keys on a single server:

SSH key selection

If you do not already have a public SSH key uploaded to your account, or if you would like to add a new key to your account, click on the “+ Add SSH Key” button. This will expand to a prompt:

SSH key prompt

In the “SSH Key content” box, paste the content of your SSH public key. Assuming you generated your keys using the method above, you can obtain your public key contents on your local computer by typing:

cat ~/.ssh/
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNqqi1mHLnryb1FdbePrSZQdmXRZxGZbo0gTfglysq6KMNUNY2VhzmYN9JYW39yNtjhVxqfW6ewc+eHiL+IRRM1P5ecDAaL3V0ou6ecSurU+t9DR4114mzNJ5SqNxMgiJzbXdhR+j55GjfXdk0FyzxM3a5qpVcGZEXiAzGzhHytUV51+YGnuLGaZ37nebh3UlYC+KJev4MYIVww0tWmY+9GniRSQlgLLUQZ+FcBUjaqhwqVqsHe4F/woW1IHe7mfm63GXyBavVc+llrEzRbMO111MogZUcoWDI9w7UIm8ZOTnhJsk7jhJzG2GpSXZHmly/a/buFaaFnmfZ4MYPkgJD

Paste this value, in its entirety, into the larger box. In the “Comment (optional)” box, you can choose a label for the key. This will be displayed as the key name in the DigitalOcean interface:

SSH new key

When you create your Droplet, the public SSH keys that you selected will be placed in the ~/.ssh/authorized_keys file of the root user’s account. This will allow you to log into the server from the computer with your private key.

How To Copy a Public Key to your Server

If you already have a server available and did not embed keys upon creation, you can still upload your public key and use it to authenticate to your server.

The method you use depends largely on the tools you have available and the details of your current configuration. The following methods all yield the same end result. The easiest, most automated method is first and the ones that follow each require additional manual steps if you are unable to use the preceding methods.

Copying your Public Key Using SSH-Copy-ID

The easiest way to copy your public key to an existing server is to use a utility called ssh-copy-id. Because of its simplicity, this method is recommended if available.

The ssh-copy-id tool is included in the OpenSSH packages in many distributions, 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 that you would like to connect to and the user account that you have password SSH access to. This is the account where your public SSH key will be copied.

The syntax is:

ssh-copy-id username@remote_host

You may see a message like this:

The authenticity of host ' (' 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 just means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type “yes” and press ENTER to continue.

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

/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@'s password:

Type in the password (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/ key into a file in the remote account’s home ~/.ssh directory called authorized_keys.

You will see output that looks like this:

Number of key(s) added: 1

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

At this point, your key has been uploaded to the remote account. You can continue onto the next section.

Copying your 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.

We can do this by outputting the content of our public SSH key on our local computer and piping it through an SSH connection to the remote server. On the other side, we can make sure that the ~/.ssh directory exists under the account we are using and then output the content we piped over into a file called authorized_keys within this directory.

We will use the >> redirect symbol to append the content instead of overwriting it. This will let us add keys without destroying previously added keys.

The full command will look like this:

cat ~/.ssh/ | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

You may see a message like this:

The authenticity of host ' (' 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 just means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type “yes” and press ENTER to continue.

Afterwards, you will be prompted with the password of the account you are attempting to connect to:

username@'s password:

After entering your password, the content of your key will be copied to the end of the authorized_keys file of the remote user’s account. Continue to the next section if this was successful.

Copying your Public Key Manually

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

The content of your file will have to be added to a file at ~/.ssh/authorized_keys on your remote machine somehow.

To display the content of your key, type this into your local computer:

cat ~/.ssh/

You will see the key’s content, which may look something like this:

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 whatever method you have available. For instance, if your server is a DigitalOcean Droplet, you can log in using the web console in the control panel:

DigitalOcean console access

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

mkdir -p ~/.ssh

Now, you can create or modify the authorized_keys file within this directory. You can add the contents of your file to the end of the authorized_keys file, creating it if necessary, using this:

echo public_key_string >> ~/.ssh/authorized_keys

In the above command, substitute the public_key_string with the output from the cat ~/.ssh/ command that you executed on your local system. It should start with ssh-rsa AAAA....

If this works, you can move on to try to authenticate without a password.

Authenticate to your 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:

ssh username@remote_host

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

The authenticity of host ' (' 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 just means that your local computer does not recognize the remote host. Type “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 required to enter it now. Afterwards, a new shell session should be spawned for you with the account on the remote system.

If successful, continue on to find out how to lock down the server.

Disabling Password Authentication on your Server

If you were able to login to 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 an account on this server with sudo access. This step will lock down password-based logins, so ensuring that you have will still be able to get administrative access is essential.

Once the above conditions are true, log into your remote server with SSH keys, either as root or with an account with sudo privileges. Open 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 through SSH using account passwords:

PasswordAuthentication no

Save and close the file when you are finished. To actually implement the changes we just made, you must restart the service.

On Ubuntu or Debian machines, you can issue this command:

sudo service ssh restart

On CentOS/Fedora machines, the daemon is called sshd:

sudo service sshd restart

After completing this step, you’ve successfully transitioned your SSH daemon to only respond to SSH keys.


You should now have SSH key-based authentication configured and running on your server, allowing you to sign in without providing an account password. From here, there are many directions you can head. If you’d like to learn more about working with SSH, take a look at our SSH essentials guide.


  • Good work. Very informative.

  • If my SSH identifier is not named “id_rsa”, SSH authentication fails and defaults to classic password authentication. Is there any way I can tell the server to look up (automatically) the name of a specific key? I know I can do this with ssh -i locally on my machine, but what I’m looking for is a way so that the server already knows which key to look for. Cheers!

    UPDATE: just found out how to do this. I simply need to create a file named “config” in my .ssh directory (the one on my local machine, not the server). The file should contain the following:

    Host REMOTE_HOST_IP # should be
      IdentityFile LOCATION_OF_YOUR_PRIVATE_KEY # for example ~/.ssh/myprivatekey (notice it's not the pub file)

    Would b great if you added this info to this doc for others! :)

  • Thanks for this article, it’s really helpful. I think there is a typo though in the ssh key copy command, the >> is missing: cat ~/.ssh/ | ssh username@remotehost “mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys”

  • Isn’t the image wrong?

    The public key is to encrypt data and private to decrypt?

    Oh I read now that it’s only to verify and they basically exchange a symmetric key, and the public key encrypts the symmetric key so that the private key can decrypt it.

    • I just found this article. I still don’t get it. It is clearly written there you do ENCRYPT message with your private key and servers DECRYPTS the message using your public key. Which I think is wrong, because public key is used for ENCRYPTION and private key for DECRYPTION. So why is the image as is and how does it finally work? Confused :-/

      • @nextdino Hello there. Yes, unfortunately, the image used here is incorrect. Overly simplified, what happens is:

        • The server generates a secret, encrypts it with the user’s public key, and sends it to the client. This is the “challenge” that the client must solve to prove that it holds the private key.
        • The client decrypts the message with the private key. It can then send a message back to the server that confirms that it was able to see the secret value.

        This is pretty simplified, but captures the general essence of the procedure. So yes, the image is incorrect. I’ve written about SSH’s encryption more in-depth in this guide if you’re interested in learning more. This section is specifically about the SSH-key authentication method. Sorry for the confusion. I hope this helps!

        by Justin Ellingwood
        SSH, or secure shell, is an encrypted protocol used to communicate with remote servers safely. The practical uses of SSH are widely discussed in other guides. In this article, we'll examine the underlying encryption and connection procedures that make SSH the go-to method of administering remote systems.
  • It is worth noting that the file ~/.ssh/authorized_keys should has 600 permissions. Otherwise authorization is not possible

  • Thanks! neatly explained

  • Very useful guide indeed, however I have one question in the final step “Disabling Password Authentication on your Server”

    Imagine that my laptop breaks or I have to format it how can i access to the server if my local ssh keys was destroyed.

  • How then should I download my private key. In this tutorial, there is no where you mentioned about downloading the private key to my machine. Which file should I the download to use on PuTTy?
    I downloaded id_rsa, but it is not recognize by PuTTy.

    • in this tutorial, it is assuming you run ssh-keygen on your local machine, so your private key (id_rsa) should already be on your computer.

      There is a more detailed walk through here if you are having trouble!

  • There is public key set between client and remote servers. The authentication is successful. However, the password for remote user expires for every three months. In this case, does resetting the password for every 3 months on remote server is required ??

  • Cool I will take a look at this this is pretty amazing

  • How would one go about adding new users when password authentication is disabled please? (Since I can’t create their key pairs and they can’t use ssh-copy-id)

  • Hello, please help me.
    After, I do as you tell. I Disabling Password Authentication on Server then I meet : “permission denied (publickey) ”
    Please help me.
    You can tell me restore a user that I creat before?

  • Hi,
    I am strugling with my ssh setup.

    This is the message I get - signandsend_pubkey: signing failed: agent refused operation. I have tried various code, but nothing seems to help. I created a digital ocean droplet with ubuntu 16.04 pre-installed. I have the same system on my pc. I followed the tutorial. Please help.

  • works perfectly (y)

  • Hi Justin,

    I did the same procedure, but now I’m getting the error saying “Permission denied (publickey).”

    debug1: kexinputextinfo: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
    debug1: SSH2
    debug1: Authentications that can continue: publickey
    debug1: Next authentication method: publickey
    debug1: Offering RSA public key: /home/dilip/.ssh/idrsa
    debug1: Authentications that can continue: publickey
    debug1: Trying private key: /home/dilip/.ssh/id
    debug1: Trying private key: /home/dilip/.ssh/idecdsa
    debug1: Trying private key: /home/dilip/.ssh/id
    debug1: No more authentication methods to try.

    Getting error like this. can you please help me resolve it.

    Also, earlier when I was on Ubuntu 14.04, I was able to ssh with root into the server. on this New Ubuntu 16.04 I believe I accessed couple of times, but now all of sudden it started giving me this error.

    Please Help me here.

    Dilip Gupta

    PS - I have my public ssh key added to DO security. I checked it through console as well.

    • Hi Dilip,
      I had the same issue and found I had a typo in my ~/.ssh/authorized_keys file. I used the vi editor and forgot to set it to insert mode before pasting. The letter ’s’ has the same affect as ‘i’, which is insert mode, so the paste cut off the first ’s’ in the key. Should be, “ssh-rsa AbunchOfRandomCharacters”.

      Hope this helps.

      • @alynch377dcc40de25edc9b804 , I got help from DO support team. and finally, I got the access by using PasswordAuthentication with root as username.

        I did modified the sshd_config file and updated PasswordAuthentication to Yes and made RootLogin true.

        I used nano editor, so in my case no typo mistakes :)

        I checked into my ~/.ssh/authorized_keys, I don’t have a mistake in my ssh key. It’s same as my local.

        Thanks for you help, though.

        Dilip Gupta

      • This resolved my issue, thanks!

  • Hi,

    I am using the Qemu based console from the config page for my droplet. I want to paste in my public ssh key but I can’t paste into the console.

    Is this something that is supported and if so, how do I get it working?



  • Really nice article. Moreover, I have required more information about key pairing within non root user. Suppose I have two server A (local) & B (Server). Both server have non root user (i.e. testClient, testSever). I would like to key pairing testClient (Local-A) and testSever (Server-B) . I have generated file in testServer using ssh-keygen command. While, I was trying ssh-copy-id in Server section with the user testServer, however still failure to key pairing with testClient user. Please help me how to solve the issue.

    • @paranduet I apologize, but I’m still a bit uncertain about what you’re trying to do. Here’s my current understanding of your setup and what you’re trying to accomplish:

      • The first server is called Local-A (or some variant) and has a non-root user named testClient
      • The second server is called Server-B (or some variant) and has a non-root user named testServer

      My understanding is that you’re trying to connect from Local-A to Server-B using these two users (logged into Local-A as testClient and SSHing to Server-B to be logged in as testServer).

      If that’s the case, the easiest way of of allowing access is to:

      1. Log into Local-A with the testClient user
      2. Run ssh-keygen to generate a public and private key for that user. The private key is kept on the host. The public key can be added to the ~/.ssh/authorized_keys file in the home directory of any user account you want to be able to log into. The ssh-copy-id command does this in the next step.
      3. Still on the Local-A computer, copy your SSH public key to the testServer user’s ~/.ssh/authorized_keys file on Server-B by typing: ssh-copy-id testServer@Server-B_IP_address. You will be prompted for the testServer user’s password in order to authenticate the request to copy your key.
      4. Test that you can log in from Local-A to Server-B by replacing the ssh-copy-id command with ssh: ssh testServer@Server-B_IP_address. This time, you should be able to log in without being prompted for a password.

      The above setup will allow you to SSH from Local-A to Server-B.

      If you want to also be able to SSH the other way around (from Server-B to Local-A), you will need to complete the procedure in reverse. I hope that helps.

  • You article is really good , but i was too late , 1 week before i was buy 10 droplet with a cost of $50 , but tomorrow some one access my droplet and used it to attack other pcs ,

    due to this reason my account has been abused and terminated …

    but know i understand how important is security .

    That’s why i come to here and try to secure my other vps , which i had purchased from other companies ..

    I have done all , what you described in above , but when i open putty and access it , i typed root as my username , i get an Putty fatal Error “ Disconnected : No Supported Authentication Methods available (
    Server Sent : publickey ) ”

  • I am using a MAC. When I try to login using ssh root@ip , it asks me for a password. Thing is I don’t know which password I am supposed to use. Could you help me out

  • Great article, one thing I’d like to add is that for SSH2 you’d need to add the public keys to authorized_keys2 file instead:

    echo public_key_string >> ~/.ssh/authorized_keys2

    Otherwise the server won’t accept your priv key.

    I had some headache due to this so mentioning it here.

  • Hi,

    I’m facing the following problem.

    I have 2 instances on aws

    1. centOS
    2. Ubuntu

    I’m trying to connect to both the machines from my centOS on virtualBox.

    I’m getting the following errors.

    centOS instance - permission denied (publickey gssapi-keyex gssapi-with-mic) Ubuntu - permission denied (publickey) Steps:

    a. created a user & passwd on local machine (centOS on virtual box).

    b. created similar users & passwd on both the instances.

    c. connected to users on each machine and then visudo'ed and added the users under root


    c. logged into user on local machine ( su user - )

    d. setup a ssh-keygen on local machine

    e. tried this cmnd on both machines ssh-copy-id user@public dns

    error on centOS instance: /bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keys Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

    error(on Ubuntu) /bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /bin/ssh-copy-id: INFO: 1 key(s) remain to be installed – if you are prompted now it is to install the new keys Permission denied (publickey).

    Please help!

  • @jellingwood

    Your SSH flow diagram doesn’t match up with your explanation; you’ve got it mixed up in your diagram.

    Your explanation:
    The associated public key can be shared freely without any negative consequences. The public key can be used to encrypt messages that only the private key can decrypt. This property is employed as a way of authenticating using the key pair.

    Your diagram: client encrypts msg with private key, server decrypts it with public key –> This part doesn’t make any sense.

  • for those who came here and still get asked for password, I had the same problem but just found out that i define costume key (IdentityFile) in my ~/.ssh/config file instead of id_rsa and remove it and now it work.

  • Whenever I reboot my droplet, the keys in the ‘authorized_keys’ file under /root/.ssh get deleted and a strange, UNKNOWN key, which I never inserted by any method, nor have I seen even in DO control panel, shows there already present. What is peculiar is that in the end of the key, where comment is written, “motherfucker” is written in these letters: “mdrfckr”

    I’ve tried deleting all keys from this file and from my DO control panel and then inserting fresh keys thru DO control panel (thinking that perhaps DO control panel takes precedence and resets the contents of this authorized_keys file at every reboot).
    Due to this, every time my droplet reboots, I’ve to delete this key and insert 2 keys from myself, one ppk key for ftp, and another openssh key for bash terminal. After inserting them, I’m able to work/login normally.

    Pls help fast. Lest there might be some intrusion into my droplet.

Creative Commons License