SSH basics

ssh user@host opens an encrypted interactive shell on the remote machine. The syntax is simple: user is the Unix account on the remote side; host is a hostname or IP address.

ssh deploy@server.example

SSH negotiates an encrypted channel (using asymmetric crypto for key exchange, symmetric for the bulk data), authenticates you (by password or key — covered in the next lesson), and drops you into a shell on the remote machine. Your terminal input goes across the encrypted channel; the remote output comes back the same way.

ssh deploy@198.51.100.10          # connect by IP
ssh deploy@server.example -p 2222 # non-default port

The default port is 22. When admins change it to reduce automated scanning noise, you pass -p PORT.

The host-key prompt implements Trust On First Use (TOFU). The very first time you SSH to a host, you see something like this:

The authenticity of host 'server.example (198.51.100.10)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZfakeFingerprint+placeholder/example.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

This is SSH telling you: “I have never seen this host before. Its public key fingerprint is X. Is that really the machine you want?” If you accept, SSH saves the host’s public key in ~/.ssh/known_hosts. On every future connection it compares the server’s key against the saved one. If they differ, SSH refuses to connect and shows a loud warning — because a mismatch means either the server was rebuilt, or something is intercepting your connection.

The right operational practice: verify the fingerprint out-of-band (from your cloud console, a provisioning system, or a colleague) before typing “yes”. In practice on trusted internal networks this step is often skipped — but for public servers, verifying matters.

~/.ssh/known_hosts stores previously trusted host keys. After you accept the prompt, the file grows by one line:

server.example,198.51.100.10 ssh-ed25519 AAAA...base64key...

If the same server is later rebuilt, its host key changes. SSH will then print a prominent warning and refuse to connect:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

To recover, remove the stale entry with ssh-keygen -R server.example and reconnect. The same warning also fires if something is doing a man-in-the-middle attack — which is why you should never just blindly remove the entry without first confirming the server was legitimately rebuilt.

~/.ssh/config eliminates flag repetition. Typing ssh -p 2222 deploy@web01.example.com on every connection is error-prone. The config file maps short aliases to full connection parameters:

Host prod
    HostName web01.example.com
    User     deploy
    Port     2222

Host staging
    HostName 203.0.113.50
    User     deploy
    Port     22

With this config, ssh prod is equivalent to ssh -p 2222 deploy@web01.example.com. The file uses indentation (spaces or tabs — SSH doesn’t care) under each Host block. HostName is the real address (the Host value is just a local alias). User sets the remote username. Port overrides the default 22.

You can also set global defaults before any Host block:

ServerAliveInterval 60
ServerAliveCountMax 3

These two lines send a keepalive packet every 60 seconds — useful to prevent idle connections from being dropped by NAT or firewalls.

~/.ssh/config also supports wildcards. A Host * block at the end applies to all connections not matched by earlier blocks:

Host prod
    HostName web01.example.com
    User     deploy
    Port     2222

Host *.example.com
    User     deploy

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

SSH reads the file top to bottom and applies the first matching value for each setting. So prod gets its specific HostName and Port, any other .example.com host gets User deploy, and every connection gets keepalives. This layering lets you avoid repeating the same values across many hosts.