SSH Session Establishment

SSH, short for Secure Shell, is a protocol for secure remote login and secure command execution over an untrusted network. It replaced older tools such as Telnet that sent credentials and terminal traffic in plain text. An SSH session gives three core properties: encryption so others cannot read the traffic, integrity so tampering is detected, and host authentication so the client can verify which server it reached.

Session setup

An SSH client first opens a TCP connection to the server, usually on port 22. The two sides exchange protocol versions and algorithm lists, then negotiate a key exchange method, an encryption cipher, and a message authentication mechanism. Using the key exchange, they derive shared session keys. From that point on, the channel is encrypted.

Before the user authenticates, the client also verifies the server's host key. The first time you connect, the client typically stores that key fingerprint in known_hosts. On later connections, if the host key changes unexpectedly, the client warns you because you may be talking to an impostor or a rebuilt server whose identity needs to be verified out of band.

User authentication

Once the encrypted channel exists, the server authenticates the user. Password authentication is possible, but public key authentication is preferred in most operational environments. With public key authentication, the client proves possession of the private key that matches a registered public key on the server. The private key never leaves the client machine.

This design is safer than password reuse, but it shifts responsibility to key management. Private keys must be protected, passphrases should be used where appropriate, and access should be revoked when a device or staff account is retired. Many production setups also layer MFA, certificate based SSH, or short lived credentials on top.

Channels inside one connection

SSH is not only for an interactive shell. Once connected, the protocol can open multiple channels over one encrypted session. One channel may run a terminal, another may transfer files with SFTP, and another may carry port forwarding traffic. Port forwarding is especially useful because it tunnels a local connection to a remote service through the SSH session. That is convenient for administration, but it can also bypass normal network boundaries if granted carelessly.

Failure modes and operational constraints

The biggest security mistake with SSH is treating it as secure by default once installed. Weak host key verification, shared admin accounts, long lived unmanaged keys, and unrestricted agent forwarding all create risk. A stolen private key with broad server access is effectively a reusable admin token.

Performance is rarely the limiting factor, but session sprawl can be. Bastion hosts, audit logs, and forced commands are common controls in larger environments. They centralise access and make it easier to answer who logged in, from where, and what they did.

SSH works because it wraps a simple idea in careful cryptography: establish a trusted encrypted channel first, then send login and command traffic through it. Everything after that depends on operational discipline around host identity, key lifecycle, and least privilege.