Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
Problem installing wordpress on subdomain (nginx / ubuntu) Question Question
cpu from 13% to 100% in one minute Question Question

Question

Permission denied (publickey) - new machine

Posted May 30, 2019 7k views
ApacheDigitalOceanSystem ToolsUbuntu 16.04DevelopmentAutomated Setups

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.

Add a comment
jarnold
By:
jarnold

Related

Join the DigitalOcean Community Community

Join 1M+ other developers and:

  • Get help and share knowledge in Q&A
  • Subscribe to topics of interest
  • Get courses & tools that help you grow as a developer or small business owner
 Join Now
Problem installing wordpress on subdomain (nginx / ubuntu) Question Question
cpu from 13% to 100% in one minute 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
3 answers
asciant 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 idrsa.pub, the private key shouldn’t really need to leave your local machine (idrsa file is the private key).

When you then connect to your new server, your local machine tries to match the private key (idrsa) with the public key on the Droplet (stored in ~/.ssh/authorizedkeys). 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).

Reply Report
  • jarnold May 31, 2019

    Great, I can actually speak to this. It is the first option, the Droplets I’m struggling with are largely set up by the dev before me (so two machines ago) which means that neither of my public keys are working. This means that his old Private Key (now long gone) was never put on either of my machines, so I can only gain access via password with the root… not an ideal situation. No SSH.

    Will I have to re-create all these droplets slowly as I need to update them, or can I somehow add my public key to droplets created over a year ago?

    Thanks a bunch

    EDIT: I would like to note that my company is incredibly small and we just sort of do what we do. This means there is no company key, but this is something I will work on regardless as time goes on to sync everything for future turn over.

    Reply Report
asciant 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.

Reply Report
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 “idrsa” 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 “idrsa” and viola…it worked!

that being said…is there a way to make the system understand i didn’t name the thing idrsa? 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 “idrsa” 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.

Reply Report

Related

Looking for something else?

Ask a new question Search for more help