What Happens When You Type a URL and Press Enter
DNS lookups, TCP and TLS handshakes, HTTP requests, servers, and the browser's rendering pipeline. The whole journey of a web page, explained so it finally clicks.
Read →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.
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.
An SSH key is a pair of files:
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.
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.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.
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
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.
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.
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:
sudo, rather than logging in as root.(Full VPS deployment walkthrough.)
Automated deploys often need SSH access:
If a private key leaks (committed to a repo, laptop stolen without a passphrase):
authorized_keys and from GitHub or GitLab.(What to do after leaking credentials.)
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.
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.
Yes. The public key can only verify you; it can't be used to log in as you. Never share the private key.
DNS lookups, TCP and TLS handshakes, HTTP requests, servers, and the browser's rendering pipeline. The whole journey of a web page, explained so it finally clicks.
Read →There are dozens of HTTP status codes, but about fifteen cover nearly everything. What each one means, when to return it, and the mix-ups (401 vs 403, 301 vs 302) that confuse everyone.
Read →A, AAAA, CNAME, MX, TXT and NS records in plain English, why DNS changes seem slow, and the troubleshooting commands that tell you what is really going on.
Read →