Stop sharing server passwords

When I started working with a software agency running 30+ projects, the access model was simple: everyone had the server passwords.

It worked, in the sense that people could get their jobs done. It also meant nobody could say who changed what, a departing developer kept their access until someone remembered to change every password, and one leaked password opened every server at once.

Here’s how we fixed it without slowing the team down.

1. One person, one key

Password logins went away. Every person got their own SSH key pair, and the server only accepts keys.

# /etc/ssh/sshd_config (the important lines)
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

This one change does most of the work. Keys can’t be guessed, and every login is tied to a specific person.

2. Roles, not everyone-is-admin

Not everyone needs the same access. We defined roles:

• Admins manage servers, users and system configuration
• Developers deploy and check their own projects
• Read-only users can look at logs and status

Even process management followed the roles. Developers could see and restart the PM2 processes for their projects, and only those. That sounds strict, but in practice it removed a whole class of “who restarted my app?” problems.

3. Only from places you trust

SSH was allowed only from approved IP addresses, enforced by both the cloud firewall and the server’s own firewall. A stolen key is much less useful when it only works from the office network or a VPN.

Today I’d go one step further and put SSH behind a mesh VPN such as Tailscale, so the port isn’t on the public internet at all.

4. Offboarding the same day

When someone leaves, their key comes out of the server configuration immediately. Because everyone has their own key, removing one person doesn’t affect anyone else. Compare that with shared passwords, where offboarding means changing every password and telling everyone who stays.

5. The rest of the basics

Access control is one layer. These sit around it:

• UFW and cloud security groups with explicit allow-lists, closing every port that doesn’t need to be open
• fail2ban to block repeated failed login attempts
• A regular patching schedule, so security updates don’t wait for someone to have time
• No direct database access from anywhere except the applications that need it

“Won’t this slow people down?”

It’s a fair worry, and the answer is no, as long as you pair it with automation.

At the same agency, we standardized server setups with templates and wrote CI/CD pipelines for dev, staging and production. New projects went live in about 30 minutes once the repo and database were ready. Developers stopped needing to touch servers at all, because the pipeline did the deploying.

That’s the real point. Locking down access works when people no longer need that access to do their jobs.

A five-minute self-check

1. Can anyone log into your servers with a password?
2. Is there any account more than one person uses?
3. If a developer left today, how long would it take to remove all their access?
4. Is SSH reachable from the whole internet?
5. Do developers log into servers to deploy?

Every “yes” is a fix worth making this month.