SSH is the most underestimated tool in a developer's workflow. Not because it's obscure, but because most people learn just enough to type ssh user@ip, hit enter, and never think about it again.
That's a mistake. SSH is not a login command. It is the foundation of every secure interaction you have with a remote machine: deployments, tunnels, file transfers, database access. Understanding it well changes how you work.
The simplest form
The basic command looks like this:
ssh username@server_ip
For example:
ssh ubuntu@192.168.1.10
The first time you connect, SSH asks whether you trust the host. You say yes, and it remembers the fingerprint for future connections. That handshake matters more than most people realize.
What actually happens when you connect
Three things occur in sequence:
- SSH negotiates encryption algorithms between your machine and the server.
- Your identity is verified, either by password or key pair.
- Every command and response travels through an encrypted channel.
This is why SSH is trusted across the industry, from solo developers to enterprise infrastructure teams. The protocol is doing real work on every connection.
Why passwords are the wrong default
Password authentication works. It is also the weakest link in most server setups. Brute-force attacks target SSH passwords constantly, and reused credentials make the problem worse.
Key-based authentication is faster, harder to compromise, and easier to automate. There is no good reason to keep using passwords once you understand the alternative.
Setting up key authentication
On your local machine, generate a key pair:
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
This produces two files. The private key (~/.ssh/id_rsa) stays on your machine and never leaves it. The public key (~/.ssh/id_rsa.pub) goes on the server.
Copy the public key over:
ssh-copy-id username@server_ip
Now log in:
ssh username@server_ip
No password prompt. No friction. Just a secure, instant connection.
The config file changes everything
Most people type full SSH commands every time. This is unnecessary.
Create ~/.ssh/config:
nano ~/.ssh/config
Add entries like this:
Host myserver
HostName 192.168.1.10
User ubuntu
IdentityFile ~/.ssh/id_rsa
Now you connect with:
ssh myserver
Clean, readable, and zero keystrokes wasted. Once you start using SSH config, you wonder how you ever worked without it.
Keeping sessions alive
SSH sessions drop when the connection goes idle. This is fixable with two lines in your config:
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
This sends a heartbeat every 60 seconds. Three missed heartbeats before the connection is considered dead. No more mid-command disconnects.
SSH agent: solving the passphrase problem
If your key has a passphrase (and it should), you will be asked for it on every connection. The SSH agent eliminates that repetition:
eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa
The agent holds your decrypted key in memory for the duration of the session. You authenticate once, and every subsequent connection is seamless.
Port forwarding: the underused superpower
SSH can tunnel traffic securely between machines. This is one of its most powerful and least understood features.
To access a remote PostgreSQL database as if it were local:
ssh -L 5432:localhost:5432 user@server_ip
Now localhost:5432 routes to the remote database through an encrypted tunnel. No exposed ports, no firewall changes, no additional tooling.
Troubleshooting the errors that trip everyone up
Permission denied (publickey). Almost always a file permission issue:
chmod 600 ~/.ssh/id_rsa chmod 700 ~/.ssh
Connection refused or timeout. Verify the SSH service is running on the server:
sudo systemctl status ssh
Host key verification failed. The server's IP changed, or it was reprovisioned. Remove the old fingerprint:
ssh-keygen -R server_ip
These three cover 90% of SSH issues. Keep them in your notes.
The deeper point
SSH rewards investment. The people who set up their config, use key authentication, run agents, and understand tunneling move through infrastructure work with almost no friction. Everyone else types the same long commands, re-enters passwords, and troubleshoots the same errors on repeat.
The protocol itself is elegant. The gap is in how much of it most people bother to learn.