SSH in a Nutshell: How It Works, What It Does, and Security Practices

If you’ve ever operated a computer remotely, you can’t avoid SSH. In the Telnet era, every line you typed into a remote terminal — passwords included — traveled the network in plaintext, and anyone on the same segment could capture the packets and read it all. In 1995, Tatu Ylönen wrote SSH after a password-sniffing attack, precisely to encrypt that naked channel. This post untangles SSH end to end: what it is, how a connection is established, what it can do beyond login, and what happens when it’s misconfigured.

What SSH Is

SSH (Secure Shell) is an encrypted network transport protocol designed to provide secure remote login and other network services over unsecured networks. The core contradiction it solves: the convenience of remote operation naturally conflicts with the confidentiality of network transport — to operate another machine you must send commands and data out over the network, and the network itself can’t be trusted. SSH’s answer is end-to-end encryption plus mutual identity verification.

Comparing it with its two neighboring protocols makes the picture clearer:

Dimension	Telnet	SSH	HTTPS
Transmitted content	Plaintext	Encrypted end to end	Encrypted
Authentication	Password sent in plaintext	Password / public key / Kerberos	Certificates
Typical uses	Remote terminal (obsolete)	Remote terminal, file transfer, port forwarding	Web traffic
Port	23	22	443

HTTPS and SSH are both encrypted protocols, but they’re positioned differently: HTTPS protects web content delivery, with its trust anchor in the CA certificate system; SSH serves ops scenarios, with its trust anchor in verifying the host key fingerprint on first connection. They are not substitutes for each other.

How a Connection Is Established

SSH establishes a secure connection in three steps, and the order matters:

Key exchange: the client and server use a Diffie-Hellman-type algorithm to negotiate, over a public channel, a session key that only they know — eavesdroppers get nothing. This step protects the channel first.
User authentication: inside the now-encrypted channel, “who are you” is verified, via password, public key, Kerberos, and other methods.
Data transfer: once authentication passes, all data travels under the session key’s symmetric encryption.

These three steps aren’t just theory — add -v when connecting and you can watch them. Below is a public-key login tested in a Rocky Linux 9 container (OpenSSH 9.9p1); the key exchange and session encryption algorithms are laid out plainly:

curve25519-sha256 is the key exchange algorithm, aes256-gcm@openssh.com is the negotiated symmetric cipher suite, and finally the public-key authentication passes and the command returns normally — the theoretical three steps map one-to-one onto the actual packets.

Capabilities

SSH is more than a remote login tool; three capabilities each open up their own scenarios:

Remote operation: securely accessing and operating another computer — the most basic usage, and the transport foundation for ops tools like Ansible and SaltStack.
File transfer: SCP and SFTP, built on top of SSH, handle secure file moves. Worth noting: since OpenSSH 9.0, the scp command is implemented on the SFTP protocol under the hood, so behaviors older scripts rely on — like glob expansion — may need adapting.
Port forwarding: forwarding arbitrary TCP ports through an encrypted tunnel to the local or remote side, letting insecure services (old databases, internal admin interfaces) ride SSH’s encrypted channel across untrusted networks.

Risks and Boundaries

SSH is a relatively secure protocol, but “relatively” deserves unpacking. It is not without weaknesses, and it’s certainly not universal insurance:

Misconfiguration is an entrance: however good the protocol’s encryption, it can’t survive a hole cut into the configuration — weak passwords, leaked private keys, PermitRootLogin left on are all ready-made paths for attackers.
Endpoint security is beyond the protocol: SSH protects the transport; when either machine at either end of the channel is compromised, it is powerless.
It doesn’t solve authorization or auditing: who can log in, what they may do once in, and what they did — those require a supporting permission system and audit logs. SSH itself only answers “is the channel secure.”

When not to use SSH: for public-facing web services, use HTTPS rather than bending port forwarding to fit; for large-scale batch administration, SSH is just the transport layer and orchestration belongs to configuration management tools; and for highly time-sensitive audio/video streams, don’t wrap them in SSH tunnels — TLS/QUIC fit better.

Security Practices

Prefer public-key authentication: far more resistant to brute force than passwords; even better combined with disabling password login (PasswordAuthentication no) and disabling root login.
Treat keys as assets: rotate them periodically, promptly remove the public keys of departed staff and decommissioned machines, and never let a private key leave its machine.
Tighten the server-side configuration: changing the default port is “invisibility,” not hardening, but AllowUsers whitelists, lockout on failure, and fail2ban-style bans genuinely reduce the attack surface.
Think before opening port forwarding: know which service it exposes to whom, and avoid accidentally bypassing firewall policy.

Notes and Cautions

SSH’s security rests on correct configuration: a misconfigured service or sloppy key management is itself an intrusion point — encryption cannot rescue configuration errors.
Among authentication methods, public-key authentication deserves priority over password authentication, and works best combined with disabled root login; Kerberos suits enterprise intranets that already run a domain.
Verify the host key fingerprint on first connection (ssh-keygen -l -f or the -v output); it’s the first — and cheapest — gate against man-in-the-middle attacks.
Don’t forget endpoint security: SSH protects the transport; when the machines at either end of the channel are compromised, the protocol is powerless.

From Telnet’s plaintext streaking to curve25519 + AES-GCM encrypting everything, SSH has spent three decades turning “remote login” from a high-risk operation into infrastructure. The protocol itself is reliable enough — what truly decides security is always the person who configures it and keeps the keys. Turn on public-key authentication, turn off password login: that’s step one, and you can finish it today.