Networking

SSH — Secure Shell

The protocol behind the single most common command an embedded engineer types: ssh user@device-ip. It gives an encrypted, authenticated terminal on a remote machine — the same core guarantees TLS provides for a web connection, applied specifically to "give me a shell on that box," with a distinct, stronger identity model built around cryptographic keys instead of certificates.

Quick reference
What it is
An encrypted, authenticated protocol for remote login, command execution, and file transfer.
Mental model
A locked door that only opens for a key you already own — the server never asks you to show it the key, only to prove you have it.
Key numbers
Port 22 by default; common key types are ed25519 (newer, preferred) and RSA (older, still widely supported).
Reach for it when
Any remote shell, file transfer, or administration task over an untrusted network — effectively always, in place of telnet or rsh.

Why SSH replaced telnet

Telnet and rsh, SSH's plaintext predecessors, sent everything over the wire exactly as typed — including the login password. Anyone able to observe the network between client and server could read credentials directly out of the traffic, the exact same problem plain HTTP has for web traffic. SSH exists to close that gap for remote administration specifically: every byte, including the password (if password auth is even used), is encrypted before it leaves the client.

Host keys — trusting the server

Before authenticating you, SSH authenticates the server — every SSH server has its own host key pair, and the client checks the server's public key against a local known_hosts file from any previous connection. This is a different trust model from TLS's certificate chain: there's no central authority vouching for a server's identity, only trust-on-first-use — the first connection asks "are you sure?" and remembers the answer. If the key ever changes afterward, SSH refuses to connect and warns loudly, since that's exactly what a machine-in-the-middle attack — or, far more often, a reimaged or reinstalled server — would look like.

Key-based authentication — proving who you are

A key pair consists of a private key (stays on your machine, never transmitted) and a public key (copied to every server you want to access, into its authorized_keys file). Logging in proves you hold the private key without ever sending it:

  1. The server sends a challenge — some data encrypted with your public key, or generated fresh for this login attempt.
  2. Only your private key can produce the correct response to that challenge.
  3. The server verifies the response against the public key it already has on file — if it checks out, you're in.

Password authentication, by contrast, transmits the actual secret (encrypted in transit, but still a reusable, guessable string) every single time — key-based auth never sends anything an attacker who captured it could reuse.

Tunneling and port forwarding

Once an SSH connection exists, it can carry more than a terminal — SSH can forward arbitrary TCP traffic through that same encrypted channel. Local forwarding exposes a remote service on your own machine's local port; remote forwarding does the reverse, exposing a local service to the remote side. A reverse SSH tunnel — a device behind NAT initiating an outbound connection to a public server, then forwarding a port back through it — is a common way to reach an embedded device for debugging when it has no public IP or inbound access of its own at all.

Real-world applications

Gotchas

Field notes