Scalable compute services.
Simple object storage.
Run managed Kubernetes clusters.
Tools & Integrations
Automate your infrastructure.
Deploy pre-built applications.
Connect, share and learn
DevOps and development guides
Questions & Answers
Development and systems Q&A
by Justin Ellingwood
Right now the only way to verify a SSH host key is to go on the console and log in to the instance. This is tedious and will result in users not checking the fingerprint.
I would like to see this feature, the fingerprint and randomart should be mailed to the customer. Especially when the customer has no keys set up and root password is mailed out.
For that matter, if you provision a droplet with only ssh keys, there's no way to log in to verify the key even if users don't mind the tedium.
Emailing the fingerprint (or putting it somewhere) would solve this.
I'd love to see the droplet's SSH fingerprint in the control panel - when connecting to a droplet for the first time it's a very good idea to verify fingerprints.
I see the wisdom in this, getting MITM'd on the first connection has been a concern for me in the past (although as far as I know it has never actually happened to me). Another possible way to protect from MITM attacks would be to use a per-account CA to sign SSH Certificates. (See https://www.digitalocean.com/community/tutorials/how-to-create-an-ssh-ca-to-validate-hosts-and-clients-with-ubuntu)
Without being able to verify the fingerprint we are open to man in the middle type attacks
Show the fingerprint in the console. Emailing it would also be okay.
I could really appreciate this feature. I often provision a droplet while I'm surfing on insecure wifi, use it to encrypt my traffic, and then axe the droplet when I'm done. This feature would make that safer and easier.
Currently, the only way to verify the fingerprint is on the console, using a root password transmitted over unencrypted, insecure email. But the proposed solution of sending the fingerprint via the same insecure channel is no better. The only way is to provide the fingerprint secured via SSL, either in the web client or via the web console. I’ve proposed this at https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/9476679-provide-the-ssh-key-fingerprint-over-secure-channe
entirely too tedious. Moving on to the next company.
How are we supposed to connect securely to new droplets without verifying fingerprints?
Please provide the newer SHA256 fingerprint format as well. The older (less secure) MD5 format should eventually be phased out, but I understand that users may still want it until everyone's up to date.
Yes and just display the ECDSA key fingerprint so you can verify first time connecting to it
I'd say display them all in both formats (the new, better SHA256 format and the older, worse MD5 format). But if I had to pick just one public key format to display it'd be Ed25519.
email is no good for this. its also vulnerable to mitm, unless do lets up load a gpg key, which would be a good idea anyway.
Making the fingerprint available via an API endpoint and in the dash should not be a difficult thing.
Internally, you know the IP of the droplet and can run 'ssh-keyscan' against it to retrieve the fingerprints on your internal network.
Host keys need to be available via API. The initial SSH login is always vulnerable to MITM if you haven't logged in via the console, which is impossible at first anyway if you're using SSH keys
You can verify the server fingerprints via the console before logging in on the Debian droplet. It doesn't work for the Ubuntu droplet (not sure about others).
Obtaining the newly created server's public key to enter into your localhost's known_hosts file is problematic. This becomes a real PITA when creating the servers programmatically via the DO API. DO does not provide the key when the droplet is created. Nor will it provide the key via an API query. To work around this I use cloud-init phone_home to provide the key. Current Ubuntu and Centos7 provide the required clout-init version
I use the user-data attribute in a POST to the DO API to provide a modified cc_phone_home.py to cloud-init. In turn phone_home POSTS the needed key to an endpoint I provide on my localhost.
This gist provides details:
You won't be notified about changes to this idea.