Secure Shell (SSH) | Teleinf Edu

1. Why SSH Was Introduced

Early remote-access and file-transfer protocols such as Telnet and FTP could send usernames, passwords, commands, and file content as plain text. An observer with access to the network path could read that traffic and capture credentials. SSH was introduced to provide a protected protocol suite for remote login, command execution, and file transfer.

As the internet became a public network, clear-text remote access created an unacceptable exposure. In 1995, Tatu Ylönen, a researcher at the Helsinki University of Technology, developed the first version of the Secure Shell protocol. The was designed as a successor to Telnet, providing an encrypted channel for remote communication. SSH is a protocol suite and is widely used to administer computers and network devices remotely.

2. Core Architecture: One Protected Connection

SSH uses a client-server model. Its transport layer negotiates cryptographic protection, and its connection layer multiplexes services over the established transport. The protocol starts the user-authentication service after transport setup and then opens channels for requested applications. A channel can close while the TCP connection carries other channels.

SSH Client and Server
An SSH session involves two components:
- SSH Client: The software on the local machine that initiates the connection. Examples include the command-line 'ssh' tool available on Linux, macOS, and Windows, or graphical applications like PuTTY.
- SSH Server (Daemon): A program, often called 'sshd', running on the remote machine. It constantly listens for incoming connection requests and is responsible for authenticating the user and providing access.
One TCP connection, port 22 by default
The entire session, including authentication, command execution, and data transfer, is multiplexed over a single TCP connection. SSH servers listen on TCP port $22$ by default, although the port is configurable. A firewall can therefore permit remote access with one rule when the server uses that port, unlike protocols that require separate control and data ports. The connection layer assigns logical channels and flow-control windows, so an interactive shell, a forwarded stream, and a file-transfer subsystem can share the transport.

3. SSH Security Properties

An SSH connection provides negotiated confidentiality, integrity protection, and authentication. Their effectiveness depends on algorithm negotiation, host-key verification, and the server's user-authentication policy. The transport also binds the exchange to a session identifier and maintains packet sequence numbers, which help prevent reuse of authentication data in another session or silent reordering of protected packets.

A. Confidentiality and encryption

After the key exchange succeeds, SSH encrypts data sent through the channel with a negotiated cipher. A passive observer cannot read that protected traffic when the algorithms and session keys remain secure. The process is two-fold:

Initial Key Exchange: When the connection is established, the client and server use , such as a Diffie-Hellman family exchange, to derive a shared secret for the session. The server host key authenticates the exchange only when the client verifies the expected host key.
Session Encryption: Once the shared key is established, all subsequent communication is encrypted using a fast and efficient algorithm, such as AES (Advanced Encryption Standard) or ChaCha20. Every character you type and every line of output is scrambled into unintelligible ciphertext.

B. Integrity protection

SSH detects modification of transmitted data. Depending on the negotiated cipher, the transport attaches a or uses an authenticated-encryption mode for each packet.

With a MAC-based cipher, the sender computes a keyed integrity value (for example, HMAC-SHA2) over the packet data and attaches the resulting MAC.
The receiver performs the exact same calculation on the received data.
If the integrity check succeeds, the receiver accepts the packet as authentic and unmodified. If it fails, the packet is discarded and the connection is typically terminated.

C. Authentication

SSH authenticates the server to the client with a host key and authenticates the user to the server with a configured user-authentication method.

Server authentication and host-key verification:
This is the step that can prevent when the expected fingerprint is verified. Every SSH server has a host-key pair. The first time you connect, the client displays the server's public-key fingerprint and asks for confirmation:
```
The authenticity of host "server.example.com ( $203.0.113.50$ )" can"t be established.
ED25519 key fingerprint is SHA256:AbCdEf123...
Are you sure you want to continue connecting (yes/no)?
```
Typing 'yes' records the key in 'known_hosts'. The fingerprint should be checked through a trusted channel before the first acceptance. On subsequent connections, the client compares the presented key with the recorded key. A mismatch produces a warning because the server may be an impostor or may have been reconfigured.
Client authentication and user login:
After the server's identity is verified, the user must prove their own identity to the server. There are two primary methods:
- Password Authentication: The user provides a username and password. SSH encrypts these credentials before sending them to the server for verification. While this is secure against network eavesdropping, it is still vulnerable to brute-force attacks and relies on strong passwords.
- Public Key Authentication: The user generates a private/public key pair and places the public key on the server, while the private key remains on the client. The client proves possession by signing session-bound user-authentication data with the private key. The server verifies the signature with the stored public key, so a password need not cross the network. This method is common for automated SSH access, provided the private key is protected and can be revoked when no longer needed.

4. The SSH Protocol Stack

The SSH protocol is layered, which separates transport protection, user authentication, and channel management.

The core documents RFC 4251, RFC 4252, RFC 4253, and RFC 4254 have Standards Track status. Concrete algorithms and extensions are selected during negotiation, so the server policy determines which variants are allowed.

Transport Layer Protocol (RFC 4253): The lowest layer, which runs on top of TCP. It handles connection setup, host-key presentation, negotiation of encryption and integrity algorithms, key exchange, and ongoing protection and validation of packets.
User Authentication Protocol (RFC 4252): This layer runs on top of the transport layer. Its sole purpose is to authenticate the client to the server using methods like password, public key, or others.
Connection Protocol (RFC 4254): This is the highest layer. It defines how multiple logical channels are multiplexed over the authenticated and encrypted transport. The channels can carry an interactive shell, port-forwarding streams, and an SFTP session within one SSH connection.

5. SSH Applications

The connection protocol lets SSH support more than interactive remote logins.

Secure File Transfer (SFTP and SCP): SFTP runs as an SSH subsystem, while traditional SCP uses SSH transport for a file-copy operation. The SSH connection protects the file content and commands according to its negotiated algorithms.
SSH Tunneling (Port Forwarding): SSH can be used to securely tunnel otherwise insecure network protocols.
- Local Port Forwarding: Allows you to securely access a service on a remote network as if it were running on your local machine. For example, you can forward a local port on your laptop to a database server running on port 3306 inside a private corporate network.
- Remote Port Forwarding: The reverse of local forwarding. It lets a listening socket on the remote server forward connections to a service on the client side. Whether this is permitted and who can connect depends on the SSH server policy.
Remote Command Execution:SSH allows for the secure execution of a single command on a remote server without opening a full interactive shell, which is essential for automation and scripting. For example: 'ssh user@server "uptime"'
Version Control Systems: Systems like Git heavily use SSH as a secure transport for pushing and pulling changes to and from remote repositories.

6. Conclusion

SSH combines transport encryption and integrity protection with host-key verification, user authentication, and multiplexed channels. This combination supports remote shells, command execution, port forwarding, SFTP, and other services over one TCP connection. Secure operation still depends on verifying host keys, selecting suitable algorithms, protecting private keys, applying an explicit server access policy, and auditing access decisions.