I can't log into my droplet. This is another post I made about the issue that did not solve my problem, but explains some of what I have tried. https://stackoverflow.com/questions/52917470/permission-denied-publickey-digital-ocean/52972508?noredirect=1#comment92856534_52972508

What I just tried:

  1. ssh-key gen. Naming the keys portfolio. Could this naming be a problem? The only keys that work on my machine are the keys with the default name id_rsa, but there cannot be more than one set with that name. There is a line in the debug that says Offering public key: RSA SHA256:blahblah /Users/ME/.ssh/id_rsa so it looks like it connecting to the wrong key??? I have tried ssh -i ~/.ssh/portfolio ME@139.xx.xx.xxx to connect to a specific private key called portfolio. Nope. Permission denied (publickey).

  2. Log into server inside DO console. nano /.ssh/authorized_keys. Copy in my public key called portfolio. Got this here

  3. Create a new user and save.
  4. Test the key pair from terminal on my mac with ssh -v -i ~/.ssh/portfolio newUSer@139.XX.XXX.XXX

Big fat Permission denied (publickey). Obviously logging in does not work either. Why? The keys match and are in place yet still do not find each other.

Further debugging: Using the digital ocean console, currently the only way I can access my droplet, I see that copy/paste does not work. Pasting in a public key results in a string of totally different characters than the real key. This even happens in nano.

  • You can access the server, so check its logs to find out why ssh authentication is failing. – Michael Hampton Nov 6 '18 at 19:11
  • run ssh with the -vvv parameter. Look at the log files of your server. Post actual errors and your configuration, not your interpretation of it. – Gerald Schneider Nov 6 '18 at 19:12
  • added debug log – Mote Zart Nov 6 '18 at 19:26
  • Still, more interesting are the server logs. The permissions of the .ssh directory and the files in there could also be relevant. Also, your question is inconsistent. You claim you created and uploaded a key called portfolio, but you are not using it. sometimes you are using the root user, sometimes not. – Gerald Schneider Nov 6 '18 at 19:33
  • The server logs are in nano in the DO console and I cannot look at them full screen or scroll through them easily. Only using the down arrow, and most of the message is off the screen. I cannot copy from here either. It's disabled. How can I get better access? – Mote Zart Nov 6 '18 at 19:38

I wanted to update how I solved this. The problem was that:

  1. The key was not making it to the server correctly. Or an incorrect version was making it.
  2. Once I got the correct keys placed, my local machine and the server were not finding the correct keys to match each other.

Solved 1. - ssh-copy-id -i ~/.ssh/mykey root@MY-IP for trying to copy the public key did not work. I also tried pasting it directly into ~/.ssh/authorized_keys in the Digital Ocean console since I was locked out locally, but many of the pasted characters were wrong. Something was screwey about the pasting function there and Digital Ocean staff didn't know anything about that.

So to work locally I reset root PW on DO console then ssh myUser@123.456.789.10 on my local machine but with a password. Then in ~/.ssh/authorized_keys I pasted in the public key and used a diff tool to make sure they were the same. This time there were.

Solved 2. - The keys still were not connecting. I could connect using only using -i flag (which means identity _file and connects the keys manually) ssh -i ~/.ssh/mykey myUser@123.456.789.10 but I didn't want to type type this every time so I make a ~/.ssh/config.

Host myapp
    User user1
    HostName 123.456.789.10
    IdentityFile ~/.ssh/mykey

Then, going ssh myappp I am able to login. Not sure why all these things are occurring. I thought maybe since I did not name them properly since id_rsa works okay, but id_rsa2 does not so not sure what would work then, but these workarounds solved this issue.

| improve this answer | |
  • The behavior you're talking about with regards to -i is exactly how the behavior is documented in the man page. There are a few default private key filenames it looks for, if you name it something else, you need to specify with -i or in your config file (which you have done). ~/.ssh/mykey is not one of the defaults. – yoonix Nov 14 '18 at 23:39
  • This workssssssssssssssssss – Merhawi Fissehaye Aug 22 at 9:29

For me it was simpler for my new droplet. I had not assigned the Firewall, with SSH on port 22 allowed, to the droplet.

| improve this answer | |
  • When the firewall blocks the connection you are not getting a "permission denied" error, but a timeout. Your answer doesn't match this question. – Gerald Schneider Apr 17 at 6:12
  • @Gerald Schneider Nevertheless, I got the OP error, I followed the instructions to no avail. Adding the firewall and thus its rules fixed the problem instantly. – Dirk Bester Apr 17 at 6:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.