SSH

What is it? #

SSH gives you an encrypted connection to a remote machine's shell. It is how almost all server administration happens.

It also does more than shells. It copies files, forwards ports through a tunnel, and runs single commands remotely without an interactive session.

The connection is verified in both directions. The server proves its identity with a host key; you prove yours with a password or, preferably, a key.

An ~/.ssh/config file removes nearly all the typing, and is the difference between fighting SSH and barely noticing it.

Think of it like this #

A secure phone line into a locked building, where both sides check credentials before anyone speaks.

The building confirms it is genuinely the right building, and you confirm you are allowed in — before any conversation happens.

Simple example #

You manage several servers, need to copy a release to one, tail its logs, and reach a database that only listens on that machine's localhost.

Code #

# Connecting
ssh [email protected]
ssh -p 2222 [email protected]          # non-default port
ssh [email protected] "df -h"          # run one command and exit
ssh -v [email protected]               # verbose: shows why authentication fails

# ~/.ssh/config — write it once, save it forever
Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod
    ServerAliveInterval 60            # keep the connection from timing out
    ServerAliveCountMax 3

Host staging
    HostName staging.example.com
    User deploy
    IdentityFile ~/.ssh/id_ed25519

Host db-internal
    HostName 10.0.1.20
    User deploy
    ProxyJump prod                    # reach a private host via the bastion

# Now: ssh prod    scp file.tar.gz prod:/tmp/    ssh db-internal

# Copying files
scp release.tar.gz prod:/srv/app/releases/
scp prod:/var/log/app/error.log ./            # from the server
scp -r ./static prod:/srv/app/                # a directory

# rsync is better for repeated transfers
rsync -avz --delete ./dist/ prod:/srv/app/current/
# -a archive (permissions, times)  -v verbose  -z compress
# --delete removes files on the server that no longer exist locally

# Port forwarding: reach a service bound to the server's localhost
ssh -L 5432:localhost:5432 prod
# Now localhost:5432 on your machine reaches PostgreSQL on the server,
# without exposing the database port to the internet.

ssh -L 8080:10.0.1.50:80 prod     # forward to another host on its network

# The host key warning
@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@

Means the server presented a different key than last time. Either the
server was rebuilt, or something is impersonating it. Verify with the
server's operator before removing the old entry from ~/.ssh/known_hosts.

How it works #

The first connection asks you to accept the server's host key, which is then stored in known_hosts. Every later connection checks it, which is what protects against connecting to an impostor.

The warning about a changed host key is one to take seriously rather than dismiss. A rebuilt server is the common explanation, but verifying rather than assuming is the correct habit.

The config file maps a short name to a host, user, port and key. After writing it, ssh prod replaces a long command, and scp and rsync use the same aliases.

ProxyJump connects through a bastion host to reach machines with no public address, which is the standard layout for private networks.

ServerAliveInterval sends a keepalive so idle sessions are not dropped by intermediate firewalls.

rsync transfers only the differences, which makes repeated deployments much faster than scp. The trailing slash on the source directory matters: with it, the contents are copied; without it, the directory itself is copied inside the destination.

Port forwarding is the safe way to reach an internal service. The database stays bound to the server's localhost, and the tunnel exists only while the session does.

ssh -v is the debugging tool. It shows which keys were offered and why authentication was rejected, which resolves most connection problems immediately.

Real-world use #

Deployments, incident investigation and database access all go through SSH. Even where a platform abstracts it away, the fallback when something breaks is usually a shell.

The bastion host pattern is standard: one hardened, publicly reachable machine, with everything else on a private network reached through it. ProxyJump makes that transparent.

Port forwarding is how people connect a local database client to a production database without exposing the port publicly. It is safer than opening the firewall, and it disappears when the session ends.

Agent forwarding — reaching a third machine using your local key — is convenient and risky, because the destination server can use your agent while you are connected. Prefer ProxyJump.

For long operations, combine SSH with tmux so the work survives a dropped connection.

Common mistakes #

• Dismissing a changed host key warning without verifying why it changed.
• Typing long connection commands instead of writing an ssh config.
• Using scp repeatedly where rsync would transfer only the differences.
• Opening a database port to the internet instead of using a tunnel.
• Running long tasks over SSH without tmux and losing them on disconnect.

Practice #

Write an ssh config entry for a server including a custom port and key. Use it to run a single remote command, copy a file with rsync, and forward a remote localhost-only port to your machine. Then connect once with verbose output and identify which key was offered and accepted.