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.
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 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).
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
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.
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.
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.
Yes and just display the ECDSA key fingerprint so you can verify first time connecting to it
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.
How are we supposed to connect securely to new droplets without verifying fingerprints?
entirely too tedious. Moving on to the next company.
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
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.
Show the fingerprint in the console. Emailing it would also be okay.
Without being able to verify the fingerprint we are open to man in the middle type attacks
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)
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.
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 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.
You won't be notified about changes to this idea.