SSH Key vs Password Authentication: Which Should You Use?

The SSH key vs password authentication question has a short answer: for almost every server you manage, use SSH key authentication and disable passwords. Keys can't be brute-forced the way an 8-character password can, they don't get typed into phishing prompts, and they let you automate logins without embedding a secret in a script. Passwords still have a narrow place, mostly during first-boot bootstrap before your key is installed. But they should not be your steady-state login method.

SSH key vs password: what actually differs

Password auth is exactly what it sounds like. You connect, the server asks for a password, you type it, and if it matches the account's stored hash you're in. The secret travels to the server on every login (encrypted inside the SSH tunnel, but it still leaves your machine).

Key auth uses a pair of files. Your private key stays on your laptop or phone and never leaves it. The matching public key sits in ~/.ssh/authorized_keys on the server. When you connect, the server sends a challenge, your client signs it with the private key, and the server verifies that signature against the public key. The private key itself is never transmitted. That single fact is why keys win on security.

Here's the practical gap:

Why keys win in practice

Run a public-facing box for a week and check the auth log. You'll see thousands of login attempts from bots trying root with common passwords.

sudo grep 'Failed password' /var/log/auth.log | wc -l

Those bots are cheap and relentless. A weak or reused password will eventually fall. A 4096-bit RSA key or an Ed25519 key won't, there's nothing to guess.

Keys also kill a whole class of human error. Nobody can shoulder-surf a key. You can't accidentally paste it into the wrong terminal or a fake login page. And when you need to give a deploy script access, you hand it a key with a forced command instead of hardcoding a password in plaintext.

The operational cost is real but small: you have to manage key files, and losing a private key means regenerating and redistributing. That's the tradeoff, and it's worth it.

When a password is still fine

I'm not going to pretend passwords are never acceptable. A few honest cases:

• First boot on a fresh VPS. Many providers hand you a root password before you've uploaded a key. You use it once to install your key, then disable password auth.
• A local VM you throw away daily. If it's not reachable from the internet, the threat model is different.
• Console/rescue access. Your provider's out-of-band console still uses a password, and that's your break-glass path if you lock yourself out.

Even in these cases, pair the password with something. A long passphrase beats hunter2, and fail2ban or rate limiting blunts the bots.

Setting up key authentication

Generate a key. Use Ed25519 unless you have a specific reason not to. The keys are short, signing is fast, and the crypto holds up.

ssh-keygen -t ed25519 -C "you@laptop"

Give it a passphrase when prompted. That passphrase encrypts the private key on disk, so a stolen laptop doesn't mean a stolen key. Load it into your agent once so you're not retyping it all day:

ssh-add ~/.ssh/id_ed25519

Copy the public key to the server. ssh-copy-id handles the permissions and appends correctly:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

Test that key login works before you touch the server config:

ssh user@your-server

Once that's confirmed, harden the SSH daemon. Edit /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin prohibit-password

Reload and keep your current session open as a safety net:

sudo systemctl reload sshd

Open a second terminal and confirm you can still log in. If key auth is broken, you don't want to find out after you've closed your only session.

This one-time setup is the foundation for everything else you do remotely, including running Docker over that connection. If you manage containers this way, the mechanics are covered in our complete guide to remote Docker management over SSH.

Doing this from your phone

Key auth isn't tied to a laptop. Docker HQ manages your servers over SSH from your phone, and it uses the same key model: your private key lives in the device's secure storage, and the app authenticates against the public key you've already placed in authorized_keys. So when a container falls over at 3am you can pull logs, restart it, or open a shell without hunting for your laptop, and you're not typing a password into a phone keyboard on public wifi. If you also want a push alert the moment a host or container goes down, that's the point where keys pay off, unattended, secure access with no secret in transit. Pricing lives on the plans page.

A note on Docker specifically

Exposing the Docker daemon is its own decision, separate from how you log in. SSH key auth secures the connection; it doesn't change the fact that whoever reaches the daemon can effectively act as root on the host. If you're weighing how to expose Docker to remote clients at all, read Docker over SSH vs TLS before you open a port. SSH with keys is usually the simpler and safer default because you're reusing an auth system you already trust.

One concrete habit: scope keys per person and per purpose. Don't share one key across the team. Give each engineer their own, and use authorized_keys options to restrict what a deploy key can do:

command="docker ps",no-port-forwarding,no-pty ssh-ed25519 AAAA... deploy@ci

That line lets a CI key run exactly one command and nothing else.

Frequently asked questions

Are SSH keys really more secure than a strong password?

Yes, for two reasons that a strong password can't fix. The key is far too large to brute-force, and the private key never leaves your machine, so it can't be captured by a phishing page or a compromised server. A strong password is still transmitted and still guessable given enough time.

What happens if I lose my private key?

You lose access from that device, but nobody gains access, the public key on the server is useless without its private half. Log in from another authorized machine (or your provider's console), remove the old public key from ~/.ssh/authorized_keys, generate a new pair, and add the new public key. This is exactly why you keep more than one key or a break-glass path.

Should I disable password authentication entirely?

On any internet-facing server, yes, once you've confirmed key login works. Set PasswordAuthentication no and reload sshd. It removes the entire brute-force attack surface. Keep a second session open while you make the change so a typo doesn't lock you out.

Can I use both a key and a password together?

Yes, and it's a good idea for high-value hosts. That's two-factor at the SSH layer. Set AuthenticationMethods publickey,password in sshd_config and the server will require a valid key and a password before granting access.

Where to go from here

Generate one Ed25519 key today, put it on your most-exposed server, confirm login, then flip PasswordAuthentication no. That's the single change with the biggest security payoff for the least effort. And if you spend time managing servers away from your desk, see how to run a VPS entirely from your phone using the same keys you just set up.