Question
ed25519 ssh keys being ignored, new droplet defaults to user password without emailing passwords
- Posted October 15, 2016
- Getting StartedMiscellaneousSecurityDebianUbuntu
- I want to create a new droplet using this public key using the ed25519 implementation of EdDSA: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPwTWZxxf3EPVd5SSlDTDMfU2Ub2L0zdDZI/4Tb0qqNZ root@syops-main
I add it by checking the checkbox while creating a new droplet.
- I try connecting to the droplet using the key, the ssh login defaults to password login.
a). DigitalOcean is not emailing me the root password. (I double checked, and emails from DigitalOcean never land in my spam folder, which I did check just in case).
b). This key works with multiple servers I use (Arch Linux, Funtoo Linux).
c). I double checked that the public key is correct in the DigitalOcean security page.
d) RSA keys work just fine
After creating a droplet with an RSA key and normally login in: 3. Adding with ssh-copy-id -f -i id_ed25519.pub root@[droplet-ip-address} works with that key. Removing the RSA key from the .ssh/authorized_hosts file then completes the workaround.
I’m asking here for awareness (of the problem and the workaround), does someone else experience the same problem?
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.
Hi @rutiloxide,
ssh-ed25519 keys are not being ignored. To make sure, I just spin up a test Droplet with one and it is working flawless.
When you try to login to your server using ssh root@ip-address, by default it will try to read for SSH keys in ~/.ssh/ (/home/sammy/.ssh/). If it is not in default place you should use ssh -i /path/to/id_ed25519 root@ip-address. So before continuing make sure this is correct.
When you create Droplet with SSH key - DigitalOcean will NOT e-mail you Root password. With keys you login without any password, so they don’t want to send passwords over mail as they look on it as not so secure way.
Beside DigitalOcean security page, make sure you selected key on Droplet creation! This is how it should look on Droplet creation.
So as I tested, it works without any problem, just like RSA key.
You can learn more about SSH keys in tutorial about it. In case you’re using Windows, this one should help you. Also if you are using Windows, make sure you selected key in Putty
Anyway, I don’t have the time to figure out what’s happening, I’ve noticed some unusual things when I’m using ECC keys, so it’s probably something upstream. It’s working fine now, I don’t have the time to test it on multiple distros and versions though to investigate properly.
@xMudrii Hi!
That’s nice. It’s working now with a Debian 8.6 and Ubuntu 16.04 droplet. Didn’t work an hour ago though. Or a couple of weeks ago. If somebody is hotpatching this now, hi!
In the context of my opening post, since I successfuly used a rsa key with a droplet and then added the key with the ssh-copy-id command, you could have deduced that I knew what I was doing. Do you really think I didn’t read that guide? How do you suppose I’ve been using ssh keys with my other servers? That means a dozen ssh logins a day with the same ssh key and the same default ssh command:
from the same fully-updated Parabola GNU/Linux box. It’s working at the moment with another server, so for the extremely paranoid, it shouldn’t be an error on my side.
I’m just a little bit suspicious that such an error happens only when I’m creating droplets, and only when I use an ed25519 key.
And of course, DigitalOcean doesn’t email me a password if I use ssh keys, from which you could also deduce that DigitalOcean does process the key. This invalidates your whole “add an ssh” checkbox theory.
Well thank you for the answer, but its mostly not needed. If it works on one droplet, that doesn’t really convince me. The correct answer is testing.
I’ll write a script to test with all the available droplet platforms I’m using and a couple of good encryption algorithms just to be sure. If a script fails for one of the encryption algorithms or platforms, I’ll know for sure.
I’m not approving an answer until a week is passed. I want a cause, not a symptom gone. I don’t want a script for autodeploying droplets to fail because of some random error.