HomeProjectsBlogContact

SSH Keys Explained: Secure Logins for Servers and Git

Passwords are the weakest way to log in to a server. How SSH keys work, how to create and use them for servers and GitHub, and the configuration that keeps your machines locked down.

SSH Keys Explained: Secure Logins for Servers and Git

If you log in to servers or push to GitHub over SSH, you're using SSH keys whether you set them up deliberately or not. Understanding them takes ten minutes and makes you much safer, because a server that accepts passwords is constantly being guessed at by bots.

How SSH keys work

An SSH key is a pair of files:

  • A private key, which stays on your computer and must never be shared.
  • A public key, which you can give to any server or service you want to access.

When you connect, the server uses your public key to challenge you, and only someone holding the matching private key can answer correctly. Your private key never leaves your machine, and there's no password for attackers to guess.

Create a key

The modern default is Ed25519, which is fast, secure and produces short keys:

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

Accept the default location (~/.ssh/id_ed25519) and set a passphrase. The passphrase encrypts the private key on disk, so a stolen laptop or leaked backup doesn't hand over access to your servers.

You now have:

  • ~/.ssh/id_ed25519: private key. Keep it secret.
  • ~/.ssh/id_ed25519.pub: public key. Safe to share.

Avoid typing the passphrase constantly

An SSH agent holds your unlocked key in memory for the session:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

macOS can store the passphrase in the keychain, and Windows has an OpenSSH agent service. Password managers like 1Password and Bitwarden can also act as SSH agents.

Add your key to a server

ssh-copy-id deploy@203.0.113.10

This appends your public key to ~/.ssh/authorized_keys on the server. Without ssh-copy-id, paste the contents of id_ed25519.pub into that file manually.

Permissions matter. SSH refuses keys if files are too open:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_ed25519

Add your key to GitHub (or GitLab)

Copy the public key:

cat ~/.ssh/id_ed25519.pub

Paste it in your account settings under SSH keys, then test:

ssh -T git@github.com

Now clone and push with SSH URLs (git@github.com:user/repo.git) instead of HTTPS.

Make life easier with ~/.ssh/config

Host prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519

Host staging
  HostName 203.0.113.20
  User deploy
  Port 2222

Now ssh prod is all you type. The config also works with scp, rsync and Git.

Lock down the server

Once key login works (test it in a second terminal before changing anything), disable password logins in /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Then reload SSH:

sudo systemctl reload ssh   # the service is called sshd on some distributions

Extra hardening:

  • Use a firewall that only allows the ports you need (SSH, HTTP, HTTPS).
  • Consider a tool like fail2ban to block repeated failed attempts.
  • Log in as a normal user and use sudo, rather than logging in as root.

(Full VPS deployment walkthrough.)

Keys in CI and deployment

Automated deploys often need SSH access:

  • Create a separate key just for CI, not your personal key.
  • Store the private key as an encrypted CI secret. (Secrets in GitHub Actions.)
  • For Git repositories, use deploy keys that grant access to one repository, read-only where possible.
  • Restrict what the key can do on the server: a dedicated user with limited permissions.

When a key is compromised

If a private key leaks (committed to a repo, laptop stolen without a passphrase):

  1. Remove the public key from every server's authorized_keys and from GitHub or GitLab.
  2. Generate a new key pair and distribute the new public key.
  3. Check server logs for unexpected logins.

(What to do after leaking credentials.)

FAQ

What is an SSH key?

A pair of cryptographic keys used to log in securely. The private key stays on your computer; the public key is placed on servers or services that should trust you.

Should I use RSA or Ed25519?

Ed25519 is the modern recommendation: secure, fast and compact. Use RSA with a large key size only for old systems that don't support Ed25519.

Is it safe to share my public SSH key?

Yes. The public key can only verify you; it can't be used to log in as you. Never share the private key.

Keep reading

More from the workbench

All articles →