SSH guide

What SSH does

Secure Shell (SSH) encrypts remote login, command execution, and file transfer over an untrusted network. The client is ssh; the server daemon is sshd. Common companions are scp and sftp for copying files, and ssh-agent for holding decrypted private keys.

How an SSH connection works

When you run ssh user@host, the typical workflow is:

1. TCP connect — client opens port 22 (or a custom port) to the server
2. Protocol banner — client and server exchange SSH version strings
3. Key exchange — algorithms are negotiated and a shared session key is established (encryption starts)
4. Host authentication — server proves its identity with a host key; client checks ~/.ssh/known_hosts
5. User authentication — password, public key, keyboard-interactive, or other methods configured in sshd_config
6. Session — on success, the server spawns a shell or runs a remote command; all traffic is encrypted on the session channel

Public-key auth is the production default: the client proves possession of a private key; the server checks the matching public key in ~/.ssh/authorized_keys (or via LDAP/CA integration).

Key files and configuration

• ~/.ssh/id_ed25519 / id_rsa — private key (never share)
• ~/.ssh/id_ed25519.pub — public key (copy to servers)
• ~/.ssh/authorized_keys — on the server; lists public keys allowed to log in
• ~/.ssh/known_hosts — on the client; trusted server host keys
• ~/.ssh/config — client shortcuts (Host aliases, IdentityFile, ProxyJump)
• /etc/ssh/sshd_config — server settings (Port, PermitRootLogin, PasswordAuthentication)

Authentication methods

• Public key — preferred; disable password auth once keys work
• Password — convenient for bootstrap; brute-force risk if exposed
• Agent forwarding — use local keys on a jump host (ForwardAgent yes); use sparingly
• ProxyJump / bastion — reach private hosts through a single entry point

Keeping sessions alive: screen and tmux

When your SSH connection drops — laptop sleep, Wi‑Fi blip, idle timeout — anything running in that shell stops unless it was started under a terminal multiplexer on the server. screen and tmux detach the session from your terminal; you reconnect later and pick up where you left off.

• screen — long-standing, available on almost every server; simple detach/reattach (Ctrl-a d, screen -r)
• tmux — more modern and capable: split panes, windows, scripting, sensible defaults; preferred for new workflows (Ctrl-b d, tmux attach)

Typical pattern: SSH in, start tmux new -s work (or screen -S work), run long jobs inside it, detach before closing the laptop. After reconnecting: tmux attach -t work or screen -r work.

This is getting mainstream again with local AI agents and coding assistants that run for minutes or hours over SSH — builds, test suites, agent loops. Without tmux or screen, a dropped connection kills the agent mid-run; with one, the work keeps going on the server until you reattach.

Hardening basics

• Disable root password login — use keys and sudo instead
• Set PasswordAuthentication no after key access is confirmed
• Use Ed25519 keys; restrict key options in authorized_keys (from=, command=)
• Limit users with AllowUsers or AllowGroups in sshd_config

Learning resources

• ssh(1) — man7.org/linux/man-pages/man1/ssh.1 (OpenSSH client)
• sshd_config(5) — man7.org/linux/man-pages/man5/sshd_config.5 (server configuration)
• ssh-keygen(1) — man7.org/linux/man-pages/man1/ssh-keygen.1 (key generation and management)
• OpenSSH manual — openssh.com/manual.html (official documentation index)