Question

Permission denied (publickey) - new machine

Hello, I am pretty new to this but I have been working on a new machine, and a new job. I have multiple droplets I am supposed to be in charge of and I am having trouble logging in. I do the classic ssh root@IP and get this root@xxx.xxx.xx.xx: Permission denied (publickey).

I have tried just about everything (resetting root, logging into the console, adding my id_rsa, adding my key, etc… I think I’ve been through every post in the last couple years that I can find on it. When I run ssh root@IP -v on one of my testing droplets here is the output:

JArnold-008110:~ jarnold$ ssh root@157.230.11.48 -v
OpenSSH_7.9p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/jarnold/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to 157.230.11.48 [157.230.11.48] port 22.
debug1: Connection established.
debug1: identity file /Users/jarnold/.ssh/id_rsa type 0
debug1: identity file /Users/jarnold/.ssh/id_rsa-cert type -1
debug1: identity file /Users/jarnold/.ssh/id_dsa type -1
debug1: identity file /Users/jarnold/.ssh/id_dsa-cert type -1
debug1: identity file /Users/jarnold/.ssh/id_ecdsa type -1
debug1: identity file /Users/jarnold/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/jarnold/.ssh/id_ed25519 type -1
debug1: identity file /Users/jarnold/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/jarnold/.ssh/id_xmss type -1
debug1: identity file /Users/jarnold/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to 157.230.11.48:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
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:LauYrYlhRFEsuWnliV3OLNHRdoNFGHWx/+yVvGdO9PI
debug1: Host '157.230.11.48' is known and matches the ECDSA host key.
debug1: Found key in /Users/jarnold/.ssh/known_hosts:1
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: Will attempt key: /Users/jarnold/.ssh/id_rsa RSA SHA256:NV+19/raPSkndui6/EzFAem14/UO+aUWqQdicJ/h9lc agent
debug1: Will attempt key: /Users/jarnold/.ssh/id_dsa 
debug1: Will attempt key: /Users/jarnold/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/jarnold/.ssh/id_ed25519 
debug1: Will attempt key: /Users/jarnold/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/jarnold/.ssh/id_rsa RSA SHA256:NV+19/raPSkndui6/EzFAem14/UO+aUWqQdicJ/h9lc agent
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/jarnold/.ssh/id_dsa
debug1: Trying private key: /Users/jarnold/.ssh/id_ecdsa
debug1: Trying private key: /Users/jarnold/.ssh/id_ed25519
debug1: Trying private key: /Users/jarnold/.ssh/id_xmss
debug1: No more authentication methods to try.
root@157.230.11.48: Permission denied (publickey).

Thanks for any help - this is my first couple weeks using DigitalOcean so I am still learning a lot, but this seems like a common question.

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

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.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

taylornavninja • October 23, 2019

codei know this is an old question…but that verbose command helped me so so much…and i have a funny feeling it was exactly what was going on above. when i used ssh-keygen to create my key i did not give it the “id_rsa” name it was expecting…i named the file something along the lines of drop-digiocean… so what i did was i renamed that private key file to “id_rsa” and viola…it worked!

that being said…is there a way to make the system understand i didn’t name the thing id_rsa? is there a crucial step i missed? it couldn’t find the file and i’m not sure it would’ve been possible had it been named anything other than “id_rsa” or any of the other filenames listed at the very bottom of that verbose log that is nearly identical to @jarnold 's .

edit:: not sure why it’s changing that from id_rsa to italics, but that is what i meant to say. apologies.

Haiden Taylor • May 31, 2019

When you say, gain access via password with the root. Does that mean you effectively have access to the server (I’m guessing through the DO console)?

If you do, you could manually add your public key to a non-root user’s authorized_keys file.

The commands would be:

  1. su - username (whatever the non-root user account is called)
  2. vi ~/.ssh/authorized_keys
  3. Scroll the end of the file, then press the O(that is capital O for Ocean) key to enter insert mode (on a new line).
  4. On your local machine (in a new terminal window/tab), type cat ~/.ssh/id_rsa.pub which will show your public key in the terminal window, select (with the mouse) and copy it.
  5. Go back to the remote machine, paste the key into the authorized_keys file.
  6. Press escape (to exit INSERT mode in vi), followed by :wq to write/save and quit.
  7. Enter exit to return to the root session.
  8. type ssh user@your_server_ip into the other terminal window and hopefully you can now remote in as the non-root user.

Even if you don’t have root access, you may be able to emulate SSH as root through the DO console. Check the docs below out, and then follow the steps above to get your public key onto the non-root user’s authorized_keys file.

https://www.digitalocean.com/docs/droplets/resources/console/

Apologies you had to wait 10 hours for a reply, I am probably on the other side of the world (Australia).

Also, lots of developers and companies have these kinds of issues. Don’t sweat it, either a company key, or some internal process to manage them appropriately will get you through.

Don’t forget to remove the old developers key from the DO account (and the authorized_keys file) and add yours/the companies key in its place.

Haiden Taylor • May 31, 2019

When creating a droplet, DO checks to see if you have a key stored on your account (https://cloud.digitalocean.com/account/security). If one exists, it is automatically added to the droplet upon creation (I’m not sure exactly of the specifics of how).

The file stored in your DO account (the key) should be the contents of id_rsa.pub, the private key shouldn’t really need to leave your local machine (id_rsa file is the private key).

When you then connect to your new server, your local machine tries to match the private key (id_rsa) with the public key on the Droplet (stored in ~/.ssh/authorized_keys). If it matches, you are allowed to login.

In your case, it appears that you have one of a couple of possible issues:

  • The key saved into your DO account (public key) doesn’t match your local machine’s key (private key). This seems quite plausible, since you said you are working on a new machine.
  • You have saved the contents of your private key into your DO account. You should have your public key in the DO account.
  • The key saved into your DO account is the company’s key, and they haven’t given you the corresponding private key.

At this point, your in for a bad day if you’re realising that you have setup all these Droplets with your old computer’s public key and haven’t backed up the private key to your new computer (doesn’t sound like it though, I’m guessing the company hasn’t hooked you up).

Try DigitalOcean for free

Click below to sign up and get $200 of credit to try our products over 60 days!

Sign up