Related

Tool DOCTL: DigitalOcean CLI Tool
Directories in Spaces are case sensitive Question Question
Can I use the canonical-livepatch service and modify the kernel while it's in use in a Droplet? Question Question

Question

Cannot ssh between 2 droplets nor to localhost

Posted April 23, 2019 2.7k views
System ToolsUbuntu 18.04

I have public keys setup for droplet creation and i am able to remote into both droplets from my computer using the key pair but if I try to ssh from Droplet 1 to Droplet 2 it fails with the following info:

Apr 23 15:03:21 18 sshd[18270]: Connection closed by authenticating user root 127.0.0.1 port 38042 [preauth]
Permission denied (publickey).

This happens on both droplets and even when connecting to localhost on the same Droplet.

UFW is disabled and sshd_config is set to the default that DO sets it to when it creates a droplet with a key file.

I have dug through everything i can find but i cannot get past this error.

Both droplets are using ubuntu 18.04

Add a comment
sales5e34c6e95e845d8da4d5e
By:
sales5e34c6e95e845d8da4d5e

Related

Tool DOCTL: DigitalOcean CLI Tool
Directories in Spaces are case sensitive Question Question
Can I use the canonical-livepatch service and modify the kernel while it's in use in a Droplet? Question Question

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
Submit an Answer
2 answers
jarland April 23, 2019

Greetings!

This means that the server you are connecting to only accepts SSH key login, and the public key for your SSH key pair does not exist in /root/.ssh/authorized_keys no that other server. If going from Droplet1 to Droplet2, then Droplet2 needs to have the public key from Droplet1 in it’s authorized_keys file. The same goes for the other way around. Here you can find some documentation on creating SSH key pairs:

https://www.digitalocean.com/docs/droplets/how-to/add-ssh-keys/create-with-openssh/

Jarland

Reply Report
  • sales5e34c6e95e845d8da4d5e April 23, 2019

    I have verified that both systems have correct keys and the problem is still there. Also, your answer doesn’t take into can’t why I cannot ssh to localhost on either machine.

    Reply Report
    • asciant April 23, 2019

      I guess the real question is, why would you want to? Why not just open a second terminal on your local machine and SSH to droplet 2?

      Correct me if I am wrong, but your saying that you would SSH from your local machine to Droplet 1 and then from the terminal window in Droplet 1 you want to be able to SSH into Droplet 2?

      The reason you can’t do that, is because the Private key component that matches the public key on both droplets is on your local machine and not on Droplet 1.

      To be able to SSH from Droplet 1 to Droplet 2 (and vice versa), as jarland points out, you need a new private/public key generated on Droplet 1 and then use SCP to transfer the public key file onto Droplet 2 ( and into ~/.ssh/authorizedkeys). It would be a terrible idea (in my opinion) to just transfer your local machine’s private key to Droplet 1, just generate a new key pair on Droplet 1 and Droplet 2 (saving the public key component of each in `~/.ssh/authorizedkeys`.

      In the article jarland provides, where it talks about your local machine you would replace that with Droplet 1.

      Reply Report
      • sales5e34c6e95e845d8da4d5e April 23, 2019

        So again i have not only verified but went back through the steps provided by Jarland with zero change. Im testing ssh between the two machines because they need direct access using sshfs. But if i cannot even get an ssh connection to localhost on either droplet nor an ssh connection from Droplet 1 to Droplet 2 then this will not work.

        Reply Report
        • jarland April 24, 2019

          The good news is that it can only be so many things. SSH tends to not just cause errors for no reason. You can try “ssh -vvv” for more output, and that may reveal more information for troubleshooting. The bottom line is that if the server finds the public key in the relevant user’s ~/.ssh/authorized_keys file and the client connects after loading the private key for the matching pair, provided that SSH has not been specifically configured to disallow this connection, then the connection works. If it doesn’t, then one of those things is not true.

          Reply Report
sales5e34c6e95e845d8da4d5e April 23, 2019
[deleted]
Reply Report

Related

Looking for something else?

Ask a new question Search for more help