SSH: Remote Access Done Right

In one line

SSH is how you actually operate a remote Linux server — and key-based authentication, not passwords, is how it's done correctly in any real production environment.

0/4 · 0%

Think of it like this

A password is like a key that opens ANY lock it fits, and can be copied, guessed, or stolen fairly easily; an SSH key PAIR is like a lock that was custom-cut specifically for one key you own, mathematically linked, where the 'lock' (your public key) can be shared freely and openly without ever compromising the 'key' (your private key) that actually opens it.

Key ideas

01
ssh user@host connects to a remote machine over an ENCRYPTED connection, giving you an interactive shell as if you were sitting at that machine directly — everything from every earlier phase (navigating, editing files, checking processes) works identically once you're connected.
02
SSH key-pair authentication: ssh-keygen generates a PRIVATE key (kept secret, stays on your own machine, NEVER shared) and a PUBLIC key (safe to share freely — it's specifically designed to be shareable). The public key gets copied to the server's ~/.ssh/authorized_keys file; from then on, the server can verify your identity using pure cryptography, no password ever transmitted or typed.
03
ssh-copy-id user@host automates copying your public key to a server's authorized_keys file in one command — the standard, easiest way to set up key-based login instead of manually editing that file yourself.
04
~/.ssh/config lets you define shortcuts and per-host settings: a block like Host myserver / HostName 1.2.3.4 / User admin / IdentityFile ~/.ssh/id_myserver means you can simply type ssh myserver instead of remembering a full connection string with a specific key file every time — a genuinely large quality-of-life improvement once you're regularly connecting to more than one server.
05
scp (secure copy) and rsync both copy files over SSH's encrypted connection — scp file.txt user@host:/remote/path/ for a simple one-off copy, rsync -avz file.txt user@host:/remote/path/ for anything larger or repeated, since rsync only transfers the parts that actually CHANGED since the last sync, meaningfully faster for large files or repeated syncs.
06
SSH TUNNELS (port forwarding) reach things that aren't directly exposed: ssh -L 5432:db.internal:5432 user@bastion makes localhost:5432 on your laptop reach a private database THROUGH the bastion; ssh -J user@bastion user@app-server (ProxyJump) hops through a bastion to another host in one command. Put these in ~/.ssh/config (Host, HostName, User, IdentityFile, ProxyJump) so you can just type ssh app-prod.
07
TMUX keeps terminal sessions alive on the SERVER: start tmux new -s deploy, run a long command, detach with Ctrl-b d (or lose your Wi-Fi), and later tmux attach -t deploy to find it still running. It also splits one terminal into panes (Ctrl-b % and Ctrl-b "), handy for watching logs while running commands. screen is the older equivalent you may find on old servers.

In your stack

→
Deploying a Spring Boot JAR to a server without a full CI/CD pipeline often looks like: scp target/app.jar user@server:/opt/myapp/app.jar followed by SSH-ing in to restart the systemd service (Phase 3.4) — a genuinely common manual deployment pattern for smaller projects before investing in real automation.

Code & diagrams

ssh-key-setup.shmarkdown

The complete key-based-auth setup, start to finish.

# Generate a new key pair (press Enter to accept defaults, or add a passphrase for extra security)
ssh-keygen -t ed25519 -C "your_email@example.com"

# Copy your public key to a server (you'll enter your password ONE last time for this)
ssh-copy-id user@your-server-ip

# From now on, this connects with NO password prompt at all
ssh user@your-server-ip

# Set up a shortcut so you don't have to remember the full details
cat >> ~/.ssh/config << 'EOF'
Host myserver
    HostName your-server-ip
    User user
    IdentityFile ~/.ssh/id_ed25519
EOF

# Now this works too, and is much easier to type
ssh myserver

# Copy a file up to the server
scp app.jar myserver:/opt/myapp/app.jar

# Or, for larger/repeated transfers, rsync (only sends what changed)
rsync -avz ./dist/ myserver:/opt/myapp/dist/

Explain it without notes

Why is SSH key-based authentication considered meaningfully more secure than password authentication?

You're setting up SSH access to a brand new server. What's the correct order of operations to avoid ever getting locked out?

Practice

Generate a fresh SSH key pair, and if you have access to any test server (even a free-tier cloud VM), practice ssh-copy-id and confirm passwordless login actually works before relying on it.

Set up an entry in ~/.ssh/config for any server you regularly connect to, and confirm the shortened ssh <alias> command works identically to the full original command.

Trade-offs

↔
Key-based auth is more secure but has real setup friction (generating, distributing, and managing keys across potentially many servers and team members) compared to a password anyone can simply type in — the security benefit is significant enough that virtually every serious production environment accepts this friction, often solving the management overhead with centralized tools (a bastion host, an SSO-integrated access system) rather than by going back to passwords.

Done when you can

I understand why SSH keys are more secure than passwords.
I can generate a key pair and set up passwordless login with ssh-copy-id.
I can copy files to/from a remote server using scp or rsync.

Command Palette