DO Ideas 2

Email me the SSH fingerprint when I start a VM

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.

  • Luke Faraone
  • Sep 11 2018
  • Attach files
  • Anonymous commented
    September 11, 2018 18:19

    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:
    https://gist.github.com/dpneumo/a71473a38451223a524ad963b06dfb9e

  • David commented
    September 11, 2018 18:19

    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).

  • Doug Thompson commented
    September 11, 2018 18:19

    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

  • Richard commented
    September 11, 2018 18:19

    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.

  • pixel commented
    September 11, 2018 18:19

    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.

  • Anonymous User commented
    September 11, 2018 18:19

    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.

  • KnowledgePower Marketing commented
    September 11, 2018 18:19

    Yes and just display the ECDSA key fingerprint so you can verify first time connecting to it

  • Anonymous User commented
    September 11, 2018 18:19

    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.

  • Anonymous User commented
    September 11, 2018 18:19

    How are we supposed to connect securely to new droplets without verifying fingerprints?

  • Anonymous commented
    September 11, 2018 18:19

    entirely too tedious. Moving on to the next company.

  • Sean DeNigris commented
    September 11, 2018 18:19

    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

  • Max commented
    September 11, 2018 18:19

    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.

  • Andrew Schulman commented
    September 11, 2018 18:19

    Show the fingerprint in the console. Emailing it would also be okay.

  • James commented
    September 11, 2018 18:19

    Without being able to verify the fingerprint we are open to man in the middle type attacks

  • Matthew East commented
    September 11, 2018 18:19

    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)

  • Anonymous User commented
    September 11, 2018 18:19

    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.

  • Stuart McMurray commented
    September 11, 2018 18:19

    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.

  • Ian Delahorne commented
    September 11, 2018 18:19

    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.