Keys
SSH, the Secure Shell, lets you type commands on a computer far away. Your laptop runs the ssh client. The server, web1, runs sshd, a program that waits for connections on port 22. Everything between them gets encrypted.
First make a key pair: ssh-keygen -t ed25519. It writes two files. id_ed25519 is the private key: keep it secret. id_ed25519.pub is the public key: safe to share. A signature made with the private key can be checked with the public one.
ssh-copy-id ana@web1 logs in once with your password and adds your public key to a file on the server: ~/.ssh/authorized_keys. That file lists the keys allowed to log in as ana.
Connecting
Now type ssh ana@web1. The client opens a TCP connection to port 22 on web1, where sshd is listening. Each side sends its SSH version, then they agree on which ciphers and key types to use.
Each side makes a one-time key pair and sends only the public half. Each mixes its own secret half with the other public half, and both get the same shared secret. It never crosses the network. From it come the keys that encrypt everything.
The server signs the exchange with its host key, which proves it is really web1. The first time, ssh shows the key's fingerprint and asks you to confirm. Answer yes and it saves the key in known_hosts, to check on every later visit.
Logging in
Now you prove who you are. Through the encrypted channel the client says: user ana, this public key. sshd looks in ana's authorized_keys file, finds the same key, and asks for proof that you hold its private half.
The client signs data unique to this connection with the private key and sends the signature. sshd checks it with the public key in authorized_keys. It matches, so ana is in. The private key itself never leaves your laptop.
Logged in. sshd starts a shell for ana on web1 and joins it to the encrypted channel. The new prompt in your terminal, ana@web1:~$, tells you that the commands you type now run on the server.
Type hostname: it travels encrypted to the shell on web1, which runs it. The answer, web1, comes back the same way. Scripts use this too: ssh ana@web1 uptime runs one command there and returns.
What happens
;; step 1/10 · remote
SSH Secure Shell: log in to and run commands
on a remote machine, over the network
client ssh on your laptop
server sshd on web1, listening on TCP port 22
network anyone on the way may see the traffic,
so SSH encrypts all of it
The terminal card shows only the commands. In real life ssh-keygen also asks where to save the key and for a passphrase, ssh-copy-id prints what it added, and the first ssh asks the fingerprint question shown in step 6. The key exchange shown is curve25519-sha256 (RFC 8731). Since OpenSSH 10.0 the default is mlkem768x25519-sha256, which mixes in a post-quantum method, but the idea is the same: a shared secret that never crosses the network. Never copy or share the private key file. If it leaks, remove the matching line from authorized_keys on every server and make a new pair. A passphrase protects the file if someone copies it.