Secure access
Make the first SSH connection
Connect as root once, verify the host-key prompt, and distinguish the server identity from your user key.
The first SSH connection checks two identities at once. Your private key proves who you are to the server. The server’s host key proves which machine answered you. People think a lot about the first and almost never about the second.
Connect with your dedicated key and the Droplet’s IP:
ssh -i ~/.ssh/digitalocean_notes [email protected]
Use your own address in place of 203.0.113.10. Since this server is not in your ~/.ssh/known_hosts file yet, OpenSSH stops and shows you something like this:
The authenticity of host '203.0.113.10' can't be established.
ED25519 key fingerprint is SHA256:9m2K...7wQ.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
Don’t just type yes
Most people type yes here without looking. I get why. But this prompt is the only moment you can catch a server that isn’t yours.
Open the Droplet’s console from the DigitalOcean control panel. That’s an independent path that doesn’t go through the network you’re about to trust. If the Recovery Console asks for a password, run DigitalOcean’s root password reset first. Then, in the console, print the host key fingerprint:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
Compare it with the prompt character by character. Only when it matches, type yes. OpenSSH saves the host key locally and drops you into an Ubuntu shell as root.
Collect the first evidence
Run:
whoami
hostnamectl --static
cat /etc/os-release
You should see root, the hostname you chose, and the Ubuntu release you picked.
When it fails
Permission denied (publickey) means the server didn’t accept your key. Check the username, the IP and the -i path first. Then check that the public key you uploaded is the one attached to this Droplet. If it isn’t, create a new Droplet with the right key. That’s safer than trying to add password login to fix it.
If, on a later connection, OpenSSH says REMOTE HOST IDENTIFICATION HAS CHANGED!, stop. A rebuild changes the host key for a good reason. An unexpected change can mean the IP now belongs to another server, or someone sits between you and it. Check the new fingerprint through the console before removing the old line from known_hosts.
Keep this root session open for the next lessons. Now open a second terminal and make the same connection again, checking the fingerprint the same way. Two working sessions give you a safety net while we change users, firewall rules and SSH settings.
Lesson completed