Only console login works - new droplet - existing SSH key used during creation - "Server refused key" error

Question

I setup my first droplet [2 years ago], added my SSH key, and can login fine from my local SSH client (MTPuTTY).

I setup a second droplet today and used the same key (autodetected during setup) and am able to login via the console.

I can see .ssh/authorized_keys on the second droplet matches the contents from the same file on the first droplet, just with an additional key added by the droplet agent on the second droplet’s file.

SO FAR SO GOOD.

I can’t login to the second droplet via MTPuTTY though. I get “Disconnected. No supported authentication methods available (server sent: publickey)” via the UI and “Server refused our key” via the log (below).

I used the same PuTTY config file, and double checked it was still pointing to the matching private key, only the IP address is different (changed to point to the second droplet).

I tried enabling UFW and opening port 22, even though this port has to be open for the console to work, right?

What else can I try to resolve this?

When I debug the SSH connection, I get:

Event Log: Connecting to xxx.xx.xxx.xx port 22
Event Log: We claim version: SSH-2.0-PuTTY_KiTTY
Event Log: Server version: SSH-2.0-OpenSSH_8.9p1 Ubuntu-3
Event Log: Using SSH protocol version 2
Event Log: Doing ECDH key exchange with curve Curve25519 and hash SHA-256
Event Log: Server also has ecdsa-sha2-nistp256 host key, but we don't know it
Event Log: Host key fingerprint is:
Event Log: ssh-ed25519 256 (deleted)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA-256 client->server MAC algorithm
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA-256 server->client MAC algorithm
Event Log: Reading key file "xxx\file_name.ppk"
Event Log: Offered public key
Event Log: Server refused our key
Event Log: Disconnected: No supported authentication methods available (server sent: publickey)

andrew · Answer

I have been facing the same problem today. I think the root cause is that in Ubuntu 22.04 and newer, ssh keys generated with RSA SHA-1 are now deprecated and not supported by default.

For me the solution was to create a new SSH key using the ECDSA protocol (I suspect RSA SHA-2 might also be an option, but I didn’t have much joy with ED25519). I had to jump through a number of hoops using root access via the Recovery Console to manually add the public key to .ssh/authorized_keys

At the moment I don’t have DigitalOcean web console access working, but that might be something else (connections hang, but there is no longer an error message in /var/log/auth.log). However, remote ssh connections from Putty are working fine.

For more, and an alternative option of enabling support for RSA SHA-1 on your new server (not recommended for security reasons, but your existing key might then work), see: https://askubuntu.com/questions/1409105/ubuntu-22-04-ssh-the-rsa-key-isnt-working-since-upgrading-from-20-04

KFSys · Answer

Hi @ipromisebank , Thre are 3 possible solutions the way I see it. The first one is, that your key doesn’t match. What I’ll recommend here is use the console to enter your Droplet and in the /root/.ssh/authorized_keys file remove the line that was added and add your public key again. The second issue that might be is that Putty is not seeking the proper private key (maybe a path issue or something similar). Lastly, if you’ve touched any permissions or ownership of the /root/.ssh folder and the files inside, the SSH service might not be able to read them. Try the first two suggestions. Sometimes it’s simple like that. Try replacing the public key in your authorized_keys file, try updating the private_key and it’s path in Putty.

Related Questions

Question

Only console login works - new droplet - existing SSH key used during creation - "Server refused key" error

Want to learn more? Join the DigitalOcean Community!

Popular Topics