DO Ideas 2

Provide the SSH Key Fingerprint Over Secure Channel

Currently, the only way to verify the fingerprint is on the console, using a root password transmitted over unencrypted, insecure email. To maintain security, the fingerprint must be available via secure channel, either in the web client or via the web console

  • Sean DeNigris
  • Sep 11 2018
  • Attach files
  • nanty commented
    September 11, 2018 16:42

    I also can't believe this is still not implemented... Should be first feature for a hosting company. I'm sure the NSA has direct acces, so there is no need to support MITM anymore.

  • Anonymous commented
    September 11, 2018 16:42

    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

  • Kotya Karapetyan commented
    September 11, 2018 16:42

    What is the status of this request? How many votes does it need before it gets attention?

  • Anonymous User commented
    September 11, 2018 16:42

    MD5 fingerprints are so passé. At least Ed25519 public keys are short enough to transcribe?

  • David commented
    September 11, 2018 16:42

    This is already in place for the Debian droplet—you can see it in the console before logging in. It doesn't work for Ubuntu and I don't know about the others.

  • Anonymous commented
    September 11, 2018 16:42

    Since you guys have local access to all the machines, you guys should try to SSH LOCALLY into newly created droplets, get its fingerprint, and then add it to the dashboard and API. Since it's a local access from digital ocean itself, there's no risk of man in the middle attacks to change the fingerprint, so the fingerprint readed will be the one provided by the machine.

  • Anonymous commented
    September 11, 2018 16:42

    When you create the droplet, in its first run, after the ssh keys generation, a script would run and send the ssh fingerprints through a secure channel to the Digital Ocean servers, which would deliver them to the user through the API or through the dashboard as a copyable string.

  • Anonymous commented
    September 11, 2018 16:42

    wow, I'm surprised this hasn't been the FIRST THING implemented in the foundation of digital ocean, it's SO OBVIOUS

  • Sean DeNigris commented
    September 11, 2018 16:42

    It's a shame this vulnerability has not been addressed. This security hole has prevented me from utilizing your otherwise great product. The setup process just can't be fully trusted…

  • Richard commented
    September 11, 2018 16:42

    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 16:42

    Couple of suggestions,
    1) have us fill out a password when making a droplet. that way, its not emailed, and we can check the host key from the console. you can still leave leave sshd to only accept keys if we have one on file since the console doesnt care how ssh is setup.

    2) have us upload gpg keys. then you can send the password along with the host keys and fingerprints.

    i second anonymous users request of both formats. newer versions of ssh cant easily verify the hex md5 sum of older ssh versions.

  • Anonymous User commented
    September 11, 2018 16:42

    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.