The Setup
A developer needed a DigitalOcean Ubuntu droplet running between Europe and Brazil. Standard cloud deployment scenario: spin up a VM, add SSH keys, connect. The basics worked. The connection didn't.
What Broke
First issue: port 22: Connection refused. The local machine had no SSH server running to accept the key copy operation. The fix required enabling SSH service and adding firewall rules:
sudo ufw allow 22
sudo systemctl start ssh
sudo systemctl enable ssh
Second issue (implied but common): SSH key permissions. DigitalOcean's standard docs skip a critical detail: the ~/.ssh directory needs 700 permissions, authorized_keys needs 600, and private keys need 600 or tighter. Get these wrong and SSH authentication fails silently with "publickey" errors.
The actual connection command: ssh root@{IP} -i {key_path}
Verification lives in /home/user/.ssh/authorized_keys on the droplet.
What This Means
This pattern plays out thousands of times daily across DigitalOcean's 700k+ active droplets. The platform doesn't enforce SSH hardening during droplet creation because different workloads need different security postures. That's defensible for developer flexibility. It's problematic for production deployments.
Three gaps enterprise teams hit:
Documentation assumes Linux literacy. DigitalOcean's tutorials cover key generation but gloss over permission troubleshooting. Third-party blogs fill the gap.
No guardrails on root SSH. Droplets allow root login by default. Production servers shouldn't. The hardening step (create sudo user, disable root) is optional and manual.
Firewall rules require activation. Adding UFW rules doesn't enable them. That's by design but catches people.
The Trade-off
Raw Ubuntu droplets give you control. They also give you rope. For development environments, that's fine. For production workloads handling customer data across regions, consider whether you need managed Kubernetes or App Platform instead of DIY server administration.
DigitalOcean's $6/month entry point and 14-region footprint work for specific use cases: development boxes, static site hosting, low-traffic APIs. Multi-region production deployments with compliance requirements? The manual hardening overhead adds up.
The SSH permission issues aren't DigitalOcean problems. They're Linux security working correctly. But the number of developers hitting these walls suggests the onboarding documentation could use more failure mode coverage.
We'll see if DO's developer focus shifts as they compete with hyperscalers for enterprise workloads. Right now, the platform assumes you know what you're doing with SSH keys. That assumption doesn't always hold.