Fingerprints are currently displayed in the console only at the first boot.

How am I on a later occasion supposed to know I’m connecting to the intended host without the fingerprint to verify with?

Using public key infrastructure (PKI) doesn’t protect against a man-in-the-middle (MITM) attack when someone has my public key and can route me to another server. I’d have to verify the server in another way. It may often be unlikely an adversary manages to construct an environment that fools me to believe it’s mine, but that’s not an acceptable verification method.

Workaround

1. Add SSH key at creation. Using a password without having verified fingerprint lets a MITM relay the traffic and monitor or modify your session. With PKI you can be misrouted to a deceptive environment, but not directly compromise the intended target server.
2. Login using SSH key.
3. Set root password to something sufficiently unique and secure.
4. Open web console.
5. Login using new root password.
6. Successful login should confirm you’re on that server.

Fix

Display the fingerprints in both hex and Base64 of applicable algorithms either in the control panel or configure Droplets to show them in console every boot.

Relevant

There’s another thread asking for fingerprints through the API.

On another note, you can avoid the risk of sending the root login credentials over email if you instead send a link where the person has to login to DigitalOcean in order to receive the password (making sure they’re in control of both email and account). But those who care to that degree may use PKI.