13.6 SSH

Introduction

Secure Shell, or SSH, is a protocol and a set of tools that let you securely access and manage remote systems over a network. It became the standard replacement for older, insecure tools such as Telnet and rlogin, which sent data, including passwords, in clear text. SSH protects both your commands and the data you send and receive by encrypting the entire session.

SSH is most commonly used to open a remote command-line shell, but it can also copy files, forward ports, and create secure tunnels for other applications. It is one of the essential building blocks of modern system and network administration.

Core Idea of SSH

At its heart, SSH provides two main things at the same time: authentication and encryption. Authentication verifies who you are and who the server is, while encryption protects the confidentiality and integrity of the data exchanged between client and server.

The typical SSH setup involves an SSH client program on your local machine and an SSH server program on the remote machine. When you connect, the client and server first agree on how to secure the connection, then they verify each other, and finally they start exchanging encrypted application data such as terminal input and output.

SSH over TCP/IP

SSH runs on top of the transport layer, most commonly using TCP port 22 on the server side. From the network’s point of view, an SSH session is simply a TCP connection between a client IP and port and the server’s IP and port 22.

This is important operationally. Firewalls, NAT devices, and security policies often look for TCP port 22 to identify SSH traffic. Administrators sometimes change the listening port to another number to reduce automated scanning, but this does not change the protocol itself, only the port on which it waits for connections.

The client connects using a URI style syntax such as ssh user@example.com, where example.com is resolved using DNS to an IP address, and the client then opens a TCP connection to port 22 of that address.

Authentication: Passwords vs Keys

SSH supports several authentication methods. For a beginner, the two most relevant ones are password authentication and public key authentication.

With password authentication, the server prompts for your username and password. This is simple but places all security on the strength of the password and server protections.

Public key authentication replaces the password with a cryptographic key pair, one private and one public. The private key stays on the client and must be protected, often with a passphrase. The public key is placed on the server, typically in a file such as ~/.ssh/authorized_keys for that user. When you connect, the server proves that it knows the associated public key, and you prove that you control the private key, without sending the private key itself over the network.

Public key authentication is widely preferred in secure environments because it resists simple password guessing or brute force attacks, and it can be combined with other controls such as passphrases and access control lists.

Host Keys and Server Identity

SSH does not only authenticate users. It also authenticates servers. Each SSH server has one or more host keys, which identify that server cryptographically.

When you first connect to a new server, the client receives its host key and usually asks you to confirm whether you trust it. If you accept, the client stores the host key in a local file such as known_hosts. On future connections, the client checks the server’s host key against the stored entry.

If the key changes unexpectedly, the client displays a warning. This can indicate that the server was reinstalled or its keys were regenerated, but it can also signal a possible man in the middle attack, where an attacker attempts to impersonate the server.

This host key mechanism is what gives SSH its resistance to impersonation and interception, as long as users pay attention to these warnings.

Secure Channels and Sessions

Once authentication and key exchange are complete, SSH sets up a secure channel over which multiple logical sessions can run. The encryption keys are typically derived during the key exchange process. After that, the entire payload of the SSH connection is encrypted.

Within a single SSH connection, you can have:

1. An interactive shell session, where you type commands and see output.
2. Non-interactive command execution, where a single command is run and the connection then closes.
3. File transfers, either directly with protocols built on top of SSH or by using tools that reuse the SSH channel.
4. Port forwarding, where traffic for other applications is carried inside the SSH encrypted stream.

This multiplexing is part of what makes SSH flexible. A single TCP connection can carry more than just a remote shell.

SSH Clients and Servers in Practice

In most operating systems, the SSH client is invoked with the ssh command. Unix like systems such as Linux and macOS typically ship with this client preinstalled. Windows now commonly includes an OpenSSH client as well.

The server side often runs the OpenSSH server, which listens for incoming connections and handles authentication and session setup. Administrators configure the server to control which users may connect, what authentication methods are allowed, and what actions users are permitted to perform once connected.

A common pattern is administrators connecting from their local machine to remote servers to perform configuration changes, monitor logs, or run troubleshooting commands. In many organizations, direct password logins are disabled, and only key based logins are allowed, with additional controls such as multi factor authentication layered on top.

File Transfer with SSH

Two common file transfer tools that rely on SSH are SCP and SFTP. Both use the SSH protocol for encryption and authentication, and both run over the same TCP port 22 as shell sessions.

SCP behaves like a simple copy command but between local and remote systems. SFTP, despite the name, is not FTP over SSH but a separate file transfer protocol that runs inside an SSH connection and offers a more advanced set of file operations.

From a networking perspective, these file transfers are indistinguishable from remote shells in terms of ports and encryption. Intrusion detection and firewalls usually identify them as SSH by port and sometimes by deep packet inspection, but the content remains encrypted.

Port Forwarding and Tunneling

One of SSH’s most powerful features is port forwarding. This allows SSH to carry other TCP connections inside its encrypted tunnel. There are three main types of forwarding.

Local port forwarding binds a local port on the client to a remote address and port accessible from the server side. You connect to the local port, and SSH forwards the traffic through the encrypted tunnel to the specified destination.

Remote port forwarding exposes a port on the SSH server side that forwards back to a port on the client or another system reachable from the client.

Dynamic port forwarding turns SSH into a sort of encrypted proxy. The client opens a local listening port that speaks a proxy protocol, and then forwards arbitrary connections through the SSH tunnel to destinations chosen dynamically.

These techniques are often used to access internal resources through a secure channel, to bypass untrusted networks, or to limit the number of open firewall holes by tunneling multiple services through a single SSH connection.

Security Considerations

SSH is designed to be secure, but practical security also depends on how it is configured and used. Weak passwords, exposed private keys, and unpatched server software can all undermine the protocol’s protections.

Servers exposed to the internet often suffer from constant automated login attempts. To mitigate this, administrators may use measures such as disabling password authentication, allowing only key based logins, restricting which users may connect, and using tools that block IP addresses after repeated failures.

From a network perspective, firewalls typically allow SSH only from specific management networks or VPNs. Security policies often require auditing of SSH activity, such as logging connection attempts and commands executed.

SSH is also a favorite for attackers once they gain access to credentials or keys, because it provides a convenient encrypted channel out of a compromised environment. For this reason, key management, key rotation, and careful monitoring are an important part of SSH security in larger environments.

SSH in Automation and Management

Beyond interactive administration, SSH is heavily used in automation. Scripts and configuration management tools use SSH to execute commands and deploy configuration changes on many remote systems.

Because SSH handles encryption, authentication, and session management, automation tools can rely on it rather than implementing their own secure transport. They can use non-interactive key based logins, often combined with restricted keys that are limited to specific commands, to reduce the potential damage if a key is compromised.

In network environments, SSH also replaces insecure management protocols for devices such as switches, routers, and firewalls. Where Telnet once provided clear text management access, SSH now provides encrypted command line sessions, often using the same SSH clients as for servers.

Summary

SSH occupies a central place in modern networking by providing secure, encrypted, and authenticated remote access over TCP. It offers remote shells, file transfer, and port forwarding inside a single protocol, and it serves both human administrators and automated tools. By understanding its basic operation, authentication methods, and typical uses, you can see how SSH fits into the broader set of application layer protocols and why it is the default choice for secure remote management.