Six hands-on simulated terminal exercises covering key generation, config files, host verification, file transfer, tunneling, and the SSH agent.
Generate an Ed25519 SSH key pair. Modern systems prefer Ed25519 over RSA — it is smaller, faster, and more secure at equivalent strength.
Type the command to generate an Ed25519 key pair with the comment student@hexworth. Partial matches accepted — focus on the algorithm flag and comment flag.
Ed25519 uses elliptic curve cryptography. A 256-bit Ed25519 key is computationally equivalent to a 3072-bit RSA key. The -C flag is just a human-readable comment embedded in the public key — it does not affect security but helps you identify keys in authorized_keys. Always set a passphrase; it encrypts the private key on disk using AES-256-CBC.
Create a ~/.ssh/config entry so you can connect to a server with a short alias instead of typing the full user@hostname -p port every time.
Open the SSH config for editing. Type: nano ~/.ssh/config — then type the config block shown below when prompted.
Host is the alias you type. HostName is the real DNS or IP. User sets the default username so you skip the user@ prefix. Port defaults to 22 — changing it via config does not affect security by itself, but port obfuscation reduces automated scan noise. IdentityFile explicitly selects a private key, which matters when you have multiple keys for different servers.
Connect to a remote server for the first time. The client will display the server's host key fingerprint and ask you to verify it — this is the Trust on First Use (TOFU) model.
Connect via SSH to 192.168.1.100 as user student. Then respond to the host key verification prompt.
The TOFU model means you trust the fingerprint the first time, and SSH saves it to ~/.ssh/known_hosts. On subsequent connections, SSH compares the server's key against the saved fingerprint. A mismatch triggers a loud warning — this is how SSH detects MITM attacks. Always verify fingerprints through an out-of-band channel (phone, ticket system) before accepting in production environments.
Use scp (Secure Copy Protocol) to transfer files over SSH. It works like cp but the source or destination can be a remote host.
Copy the local file report.txt to the home directory of student on 192.168.1.100. Use the recursive flag format as a model for directories.
The pattern is scp [flags] source destination. Remote paths use user@host:path. A bare : means the remote home directory. Use -r for directories, -P port (capital P, unlike ssh -p) for non-standard ports. For large transfers or resumable copies, consider rsync -avz --progress over SSH instead.
Create an encrypted tunnel that maps a port on your local machine to a port on a remote server's network. This lets you securely reach services that are not publicly exposed.
Forward local port 8080 to localhost:80 on the remote server at remote.hexworth.lab as user student. Add -N to prevent an interactive shell from opening.
YOUR MACHINE REMOTE SERVER ┌───────────────────┐ ┌───────────────────┐ │ │ │ │ │ Browser │ │ Web App │ │ http://localhost:8080 ──SSH──► :80 (internal only) │ │ │ │ │ └───────────────────┘ └───────────────────┘ │ │ └──────── Encrypted Tunnel ─────────┘ ssh -L 8080:localhost:80 student@remote Remote vs Local Forward: -L (Local) → YOUR port opens, traffic goes TO remote -R (Remote) → REMOTE port opens, traffic comes BACK to you -D (Dynamic) → SOCKS proxy, all traffic routed through SSH
Local (-L) is for reaching remote-internal services from your machine (e.g., a database not on a public port). Remote (-R) is for exposing a local service to the remote side — useful for demos or bypassing NAT. Dynamic (-D) turns SSH into a SOCKS proxy for routing all browser traffic. The -N flag means "no command" — just hold the tunnel open without allocating a PTY.
The SSH agent stores your decrypted private key in memory so you type your passphrase once per session instead of on every connection. Start the agent, then load your key into it.
Start the SSH agent and export its environment variables in a single shell command.
Never enable ForwardAgent yes to untrusted servers. Agent forwarding lets the remote server use your local SSH agent to authenticate onward — but a compromised or malicious server can hijack the socket and impersonate you. Use jump hosts (-J flag or ProxyJump directive) instead — they forward the connection without exposing your agent socket.
Complete all six exercises to mark this lab finished and record your progress.