Articles

SSH and remote administration: keys, sessions and the shape of a connection

Host key, user key and session: what SSH establishes, and the settings that harden it.

Reading: 7 minServer & Virtualization

Article cover: SSH and remote administration: keys, sessions and the shape of a connection

SSH is the default way to reach a Linux server, and because it usually works the first time, its mechanics stay invisible until something breaks: a key refused for the wrong permissions, a host key that changed after a rebuild, an sshd_config edit that locks everyone out. This sheet describes the shape of a connection — host key, user key, session — and the handful of decisions that turn a working login into a defensible one.

The shape of a connection

Every SSH connection establishes three things in order. The transport layer encrypts the channel; the server proves its identity with a host key, which the client remembers in ~/.ssh/known_hosts; and the user proves theirs, by public key or by password. That first step is the one people forget. StrictHostKeyChecking defaults to ask: a new host key is added only after you confirm it, and a changed key makes the client refuse the connection — the intended signal that the machine may not be the one you think it is. After a legitimate rebuild the stale entry is removed deliberately, with ssh-keygen -R hostname.

Keys instead of passwords

A key pair has a private half, which never leaves the client, and a public half, which is copied into the server’s ~/.ssh/authorized_keys. ssh-keygen -t ed25519 generates a pair — Ed25519 is a modern, compact choice, and RSA remains an option where it is still required — and ssh-copy-id user@host installs the public key. Permissions here are not cosmetic: the client ignores a private key that others can access, and sshd, with its default StrictModes, will not use a home directory or authorized_keys that group or others can write. When a key that looks correct is refused, the mode is the first thing to check. The public key is not secret, so authorized_keys may be readable, but it must not be writable by anyone except its owner. A passphrase on the private key protects it at rest, and ssh-agent with ssh-add keeps it unlocked in memory for the session rather than retyping the passphrase for every connection.

Configuring the server

The daemon reads /etc/ssh/sshd_config, and both Ubuntu and RHEL include a drop-in directory; because OpenSSH uses the first value it finds for a directive, a file in /etc/ssh/sshd_config.d/ can override the main file. The directives that matter to most baselines are few: PasswordAuthentication no once keys work, PermitRootLogin prohibit-password (already the default), AllowUsers or AllowGroups to name who may log in at all, and Port to move the listener. Before restarting the service, validate the file with sshd -t — a syntax error can stop the daemon starting, and on a remote host that is a lockout.

Sessions, multiplexing and tunnels

ControlMaster, ControlPath and ControlPersist let successive connections to the same host reuse one TCP connection, removing the per-connection handshake. For work that must survive a dropped link, a terminal multiplexer such as tmux runs on the server and detaches the session from the connection.

SSH also forwards ports over the encrypted channel, and the three forms are worth memorising:

# -L: reach a service that the server can see, through a local port
ssh -L 8080:db.internal:5432 user@bastion

# -R: publish a local service on the remote side
ssh -R 9000:localhost:3000 user@public-host

# -D: a local SOCKS proxy that routes through the server
ssh -D 1080 user@server

-L makes a local port forward to a destination reachable from the server; -R does the reverse, exposing a local service on the remote machine; -D opens a dynamic SOCKS proxy. -J reaches an otherwise unreachable host through a jump host in one step.

Limits and the common errors

Two failures are worth recognising first. The first is a key that is correct but refused because the private key is readable by others, or because ~/.ssh, authorized_keys or the home directory is writable by group or others — the fix is ownership and mode, not a new key. The second is a host key that has changed: the client warns loudly, and the right response is to establish why it changed — a rebuild, a new instance — before clearing the old entry with ssh-keygen -R, never to switch host-key checking off. A third, self-inflicted failure is editing sshd_config and restarting without sshd -t: a bad directive can stop the daemon and leave no way back in. Agent forwarding (ssh -A) carries its own caution: anyone who can reach the forwarded socket on the remote host can use your keys to authenticate, though they cannot read the key material itself — a jump host is often the safer pattern.

Level and prerequisites. L2 — operational. It assumes the L1 ideas of users, groups and file permissions, and it names the host firewall only where a rule must allow port 22.

Where to go next

References