Can't login into new instance Permission Denied (publickey)

November 4, 2016 10.3k views
Linux Basics Ubuntu 16.04

Rebuilt an image and now I can't login into my instance!

my /etc/hosts file has my ip address under howlit

Here is my output from: ssh -vv root@howlit

debug1: Host 'howlit' is known and matches the ECDSA host key.
debug1: Found key in /Users/kyle.calica-steinhil/.ssh/known_hosts:40
Warning: Permanently added the ECDSA host key for IP address 'XXX.XX.XX.XXX' to the list of known hosts.
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/kyle.calica-steinhil/.ssh/id_rsa (0x7fe5a8500950),
debug2: key: /Users/kyle.calica-steinhil/.ssh/id_dsa (0x0),
debug2: key: /Users/kyle.calica-steinhil/.ssh/id_ecdsa (0x0),
debug2: key: /Users/kyle.calica-steinhil/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/kyle.calica-steinhil/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/kyle.calica-steinhil/.ssh/id_dsa
debug1: Trying private key: /Users/kyle.calica-steinhil/.ssh/id_ecdsa
debug1: Trying private key: /Users/kyle.calica-steinhil/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Changed anything with my IP address to 'XXX.XX.XX.XXX'

2 Answers

Make sure you didn't changed private key any time after creating Droplet.
If you used one key on Droplet creation, and changed it (even in Control Panel), the original one key will be used.

/* Comment
I guess this is a OK behavior. If you go to Settings -> Security, change existing SSH key it'll generate new key fingerprint. Droplets identify SSH keys by fingerprint, not by name so I guess it's correct.
I will verify this behavior with DigitalOcean and maybe I update this */

To debug this, you can use DigitalOcean Web Console. Login to Control Panel, select your Droplet and click Console on right side.
If you have non-root user, use it in combination with password and you will be able to login.
If you have root user only and don't have password, you can use Reset Root Password from 'Access' option of Droplet details. It'll be mailed to your password and you can login with it via Console.
Probably you will have to change it on first login, you will be first asked for current password then 2 times for new one.

You can take look at SSH keys tutorial for steps. You will need to copy it manually as ssh-copy-id is not available via Console.
You can temporary enable password authentication. Open SSH config:

  • sudo nano /etc/ssh/sshd_config

Find out PasswordAuthentication to yes:

PasswordAuthentication yes

Save file and exit editor. It requires you to restart SSH service:

  • sudo systemctl restart sshd

After this you can use SSH with password to debug. Once public key starts to work, make sure PasswordAuthentication is set to no and restart service to disable password logins.

by Etel Sverdlov
SSH keys provide a more secure way of logging into a virtual private server with SSH than using a password alone. With SSH keys, users can log into a server without a password. This tutorial explains how to generate, use, and upload an SSH Key Pair.

I had the same problem, and after 4-5 hours I realize the problem and found the solution.

I'm not sure about the reason, but the server only allows keys with 1024 bytes. You can:

  1. create a 1024 key locally: ssh-keygen -t rsa -b 1024 -N "" -f ~/.ssh/id_rsa_docean
  2. add it to the keys in your profile
  3. use it to create the droplet
  4. use it to login: ssh root@YOUR_IP -i id_rsa_docean

Because of another bug, maybe using more than 1 key may fail because the authorized_keys may corrupt.

I'd love to know why those two problems: the authorized_keys mess and the size limit in the key.

Have another answer? Share your knowledge.