Permission denied (publickey) when setting up second SSH keys

October 20, 2018 3.2k views
DigitalOcean Linux Commands

I have a droplet that works with SSH but the keys are named the default id_rsa. When I add new keys they do not work. I’ve copied and pasted the public key into the digital ocean control panel in the working droplet. In the non-working droplet I tried this, as well as going ssh-copy-id root@206.***.***.104 but even this comes back as denied.

I know the permission are okay since the app with the default key names work.

I’ve tried simply naming them id_rsa2 and id_rsa_sinatra, but this does not work.

I tried to add the path to the private key ssh -i /Users/me/.ssh/id_rsa2 root@206.***.**104. No dice.

I’ve tried adding a config file to the SSH folder as follows (I am not at all confident that this is correct. It is scavenged from other posts):

Host sinatra_app
  HostName 206.***.***.*04
  AddKeysToAgent yes
  UseKeychain yes
  User root
  PubKeyAuthentication yes
  IdentityFile  ~/.ssh/id_rsa2
  User ****
  IdentitiesOnly yes

Using ssh -v root@888.000..... I get this:
debug1: Reading configuration data /Users/me/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to 206.***.***.104 port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 206.***.***.104:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:AfTvjUf8r80AyTpEkhrPShNm7viLZNwj0/lIlKxPM5E
debug1: Host '206.***.***.104' is known and matches the ECDSA host key.
debug1: Found key in /Users/me/.ssh/known_hosts:7
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:Ga8Ww/neSf7llHCfb3r6171pNb0RKyKVzdYFanRAo6o /Users/me/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/me/.ssh/id_dsa
debug1: Trying private key: /Users/me/.ssh/id_ecdsa
debug1: Trying private key: /Users/me/.ssh/id_ed25519
debug1: No more authentication methods to try.
root@206.***.***.104: Permission denied (publickey).

I’m stumped.

6 comments
  • So I destroyed the droplet and tried again. I got a little further but when I changed it to without-password in the sshd_config, it would not allow me to login, even though the password was correct.
    I rebuilt the droplet again, and then tried to add SSH keys but I get the message about someone doing something nasty. So now I cannot even add SSH keys.

    I guess destroying and trying again is the only choice. I’ll have to keep SSH and PW since removing PW killed the process again. Why can’t I remove PW authentication?

  • To disable password auth you must add this line: “PasswordAuthentication no”

  • So I’ve created and destroyed the droplet so many times and it still will not work.

    The latest problem is I get the keys to match, change PasswordAuthentication no" and then restart service sshd restart and then I get Permission denied (publickey) denied again.

    Inside of /etc/ssh/authorized_keys (I am logged in via the digital ocean console) the public key here matches my machines public key. Still, denied.

    I added this that asks for help and tried to describe what I have tried - https://stackoverflow.com/questions/52917470/permission-denied-publickey-digital-ocean

  • Maybe this can help you.

  • haha. I wish it was as simple as that!. I read everything I could find long before I posted here.
    The post u sent me works if the key is named the default, as it did for another droplet I have where I followed the tutorial and it worked. But now that the key has a new name it doesn’t work.

    Anyway, there is some part of the process I am screwing up and I don’t know what that is. Copying the wrong key? Using a config file that has syntax errors? Something else.

  • Show 1 more comments
Be the first one to answer this question.