Introduction
Every time you log into a server, copy a file to it, or push code to a Git host, there's a good chance SSH is doing the work. It's the quiet workhorse of remote computing: a secure way to reach another machine over an untrusted network. If you manage a VPS, you'll use it every day, so it's worth understanding properly.
The Problem SSH Solves
Early remote-login tools like Telnet and FTP sent everything, including your password, as plain text. Anyone on the same network path could read it. That was fine for a small trusted lab and a disaster for the internet.
Remote access needs three guarantees:
- Privacy โ Nobody in the middle can read what you send
- Authentication โ The server knows it's really you, and you know it's really the server
- Integrity โ Nobody can alter your commands or output in transit
The SSH Approach
SSH (Secure Shell) wraps your connection in strong encryption and uses cryptographic keys to prove identity. It started as a login tool, but it grew into a general-purpose secure channel: you can run commands, transfer files, and tunnel other network traffic through it.
Core idea: Instead of proving who you are with a password that can be guessed or stolen, prove it with a key pair that never leaves your machine.
Simple Example
ssh deploy@203.0.113.10
That's a secure shell on a remote machine. Everything you type and everything you see is encrypted.
Keys, Not Passwords
How Key Pairs Work
You generate two linked files:
- A private key, which stays on your computer and is never shared
- A public key, which you place on every server you want to access
The server checks that you hold the matching private key without the key ever crossing the network.
Creating and Installing a Key
# On your own computer
ssh-keygen -t ed25519 -C "you@example.com"
# Copy the public key to the server
ssh-copy-id deploy@203.0.113.10
ed25519 is a modern, compact, and fast key type. Give the private key a passphrase when asked, so that a stolen laptop doesn't mean a stolen server.
Once your key works, you can turn off password logins on the server by setting PasswordAuthentication no in /etc/ssh/sshd_config and reloading the service. Test a second login before closing your current session.
Everyday SSH Power Tools
A Config File That Saves Typing
Instead of remembering IP addresses and usernames, put them in ~/.ssh/config:
Host blog
HostName 203.0.113.10
User deploy
IdentityFile ~/.ssh/id_ed25519
Now ssh blog is all you need, and the same alias works with scp, rsync, and Git.
Copying Files
# Copy one file to the server
scp backup.sql blog:/home/deploy/
# Sync a folder efficiently (only changed files are sent)
rsync -avz --exclude '.git' ./ blog:/srv/blog/
Port Forwarding
SSH can tunnel a port from the server to your own machine, which is handy for reaching something that isn't exposed to the internet:
# Reach the server's local PostgreSQL on localhost:5433
ssh -L 5433:localhost:5432 blog
While that session is open, connecting to localhost:5433 on your computer reaches port 5432 on the server. The database never has to be open to the world.
Running a Single Command
ssh blog 'sudo systemctl status blog'
SSH runs the command, prints the result, and returns you to your own shell. This is the basis of many simple deployment scripts.
Why This Matters
-
Security by default โ Strong encryption and key-based authentication are built in.
-
One tool, many jobs โ Shell access, file transfer, tunnels, and Git hosting all use the same protocol.
-
Scriptable โ Because it works from the command line, anything you do over SSH can be automated.
-
Universal โ Every Linux server, most network devices, and every major Git host speak SSH.
Key SSH Commands
| Command | Purpose | Example |
|---|---|---|
ssh |
Open a remote shell | ssh blog |
ssh-keygen |
Create a key pair | ssh-keygen -t ed25519 |
ssh-copy-id |
Install your public key on a server | ssh-copy-id blog |
scp |
Copy files over SSH | scp file.txt blog:~/ |
rsync |
Sync folders over SSH | rsync -avz ./ blog:/srv/blog/ |
ssh-add |
Load a key into the agent | ssh-add ~/.ssh/id_ed25519 |
Habits That Keep a Server Safe
- Disable root login and password authentication once your key works
- Protect your private key. It should be readable only by you (
chmod 600 ~/.ssh/id_ed25519) - Use a passphrase and
ssh-agent, so you type it once per session instead of every time - Keep the SSH server updated, ideally with automatic security updates
- Check host key warnings. If SSH says a server's key changed unexpectedly, find out why before continuing
- Keep a second session open while changing SSH settings, so a mistake can't lock you out
Getting Started
-
Check that SSH is installed:
bash ssh -V -
Generate a key with
ssh-keygen -t ed25519. -
Install it on your server with
ssh-copy-id. -
Add a host entry to
~/.ssh/configso you can connect with a short name. -
Try a tunnel or an
rsynconce, to see how much more SSH can do than open a shell.
Know the Limits
- A leaked private key is a leaked server. Guard it, and use passphrases.
- Exposed port 22 attracts bots. Key-only login, a firewall, and optionally a tool like fail2ban keep the noise harmless.
- Lockouts happen. Know how to reach your provider's web console before you edit SSH settings.
The Philosophy
SSH isn't flashy, and that's why it's trusted. It does a small number of things, encrypting, authenticating, and moving bytes, and it does them well enough that the rest of the internet's tooling is built on top of it.
Learn it once: keys, a config file, rsync, and a tunnel. Those four skills cover most of what you'll ever need from a remote server.
This post is part of a series on the tools behind this blog: Django, HTMX, Tailwind CSS, PostgreSQL, SQLite, Docker, Debian on a VPS, tmux, and now SSH. Posts are authored in the Django admin as Markdown and rendered to HTML on save.