SSH (Secure Shell)

A network protocol that lets you securely log into a remote computer and run commands on it, as if you were sitting right in front of it — with all communication encrypted so nobody can eavesdrop.

---

What is SSH?

Every server that powers a website, runs an application, or stores data needs to be managed. Someone has to install software, update configurations, check logs, and fix problems. But these servers are rarely in the same room as the person managing them — they could be in a data centre on another continent.

SSH (Secure Shell) is the protocol that makes this possible. It creates an encrypted tunnel between your computer (the client) and a remote machine (the server), allowing you to type commands on the remote machine as though you were physically there. Everything that travels through this tunnel — your password, your commands, the output you see — is encrypted, which means anyone intercepting the traffic sees meaningless noise.¹

SSH was created in 1995 by Finnish researcher Tatu Ylonen after a password-sniffing attack at his university. Before SSH, the standard tool for remote access was Telnet, which sent everything — including passwords — in plain text across the network. SSH replaced Telnet by solving one critical problem: making remote access secure by default.²

Today, SSH is the standard way to manage servers, transfer files, and automate deployment pipelines. If you have ever typed ssh user@server.com in a terminal, you have used it.

In plain terms

SSH is like making a phone call through a soundproof, private line. You dial the remote computer, prove who you are, and then have a private conversation where you give instructions and hear results — and nobody else on the network can listen in.

---

At a glance

How an SSH connection works (click to expand)

sequenceDiagram
    participant C as Your Computer (Client)
    participant S as Remote Server

    C->>S: 1. Connection request (TCP port 22)
    S-->>C: 2. Server sends public key
    Note over C,S: 3. Both negotiate encryption (key exchange)
    C->>S: 4. Client authenticates (password or key)
    S-->>C: 5. Access granted — encrypted session begins
    Note over C,S: All traffic is now encrypted
    C->>S: Commands (e.g., ls, restart service)
    S-->>C: Output (file listings, logs, confirmations)

Key: The client initiates a connection on port 22. After negotiating encryption and verifying identity, a secure session begins. Every command and response travels through the encrypted tunnel.

---

How does SSH work?

An SSH connection happens in three phases: transport, authentication, and session. Each phase solves a different problem.

1. Transport — establishing encryption

When you type ssh user@server.com, your computer opens a TCP connection to port 22 on the server. Before any sensitive data is exchanged, the two machines agree on how to encrypt the session.³

This negotiation uses a technique called the Diffie-Hellman key exchange — a method that allows two parties to agree on a shared secret over an insecure channel without ever sending the secret itself. The result is a session key: a symmetric encryption key that both sides use to encrypt and decrypt all traffic for this session.³

The server also presents its host key — a public key that identifies the server. The first time you connect to a server, your client stores this key. On future connections, it compares the server’s key to the stored one. If they don’t match, SSH warns you that someone might be impersonating the server (a “man-in-the-middle” attack).¹

Think of it like...

Two people meeting in a crowded room who need to agree on a secret code word. Diffie-Hellman is the clever trick that lets them do this by shouting partial clues back and forth — even though everyone in the room can hear the clues, only the two of them can combine them into the final code word.

---

2. Authentication — proving who you are

Once the encrypted tunnel is established, the server needs to verify that you are who you claim to be. SSH supports two main methods:

Password authentication. The simplest method: you type your password, and it travels through the encrypted tunnel to the server. The server checks it against its user database. This works, but it is vulnerable to brute-force attacks if the password is weak.

Key-based authentication. The more secure method. You generate a key pair: a private key (stays on your computer, never shared) and a public key (placed on the server). When you connect, the server sends a challenge encrypted with your public key. Only your private key can decrypt it, proving your identity without ever sending a password.⁴

Method	Security	Convenience	Best for
Password	Moderate — depends on password strength	Simple setup	Quick access, temporary servers
Key pair	High — nearly impossible to brute-force	Requires initial setup	Production servers, automation

Key-based authentication step by step (click to expand)

1. You run ssh-keygen on your computer. This creates two files: ~/.ssh/id_ed25519 (private) and ~/.ssh/id_ed25519.pub (public).
2. You copy the public key to the server’s ~/.ssh/authorized_keys file (using ssh-copy-id or manually).
3. When you connect, the server encrypts a random challenge with your public key and sends it.
4. Your client decrypts the challenge with your private key and sends back the answer.
5. The server verifies the answer. If it matches, you are in — no password needed.

Concept to explore

See ssh-keys for a deeper dive into key generation, key types (RSA vs ed25519), and key management best practices.

---

3. Session — working on the remote machine

After authentication, you have an interactive terminal session on the remote server. Every keystroke you type is encrypted, sent through the tunnel, executed on the server, and the output is encrypted and sent back to your screen.

But SSH is not limited to interactive terminals. A single SSH connection can carry multiple channels, each doing something different:¹

• Shell session — an interactive command line
• Command execution — run a single command and get the result (e.g., ssh server "df -h" to check disk space)
• File transfer — SCP and SFTP use SSH as their transport layer
• Port forwarding — tunnel other network traffic through the encrypted SSH connection

Concept to explore

See ssh-tunneling for how port forwarding lets you securely access services behind firewalls, and scp-sftp for file transfer over SSH.

---

Why do we use SSH?

Key reasons

1. Encryption by default. Every byte of communication is encrypted. Unlike older protocols (Telnet, rlogin), there is no way to accidentally send data in plain text. This protects passwords, commands, and output from eavesdropping.²

2. Strong authentication. Key-based authentication is virtually immune to brute-force attacks. A 256-bit ed25519 key would take longer than the age of the universe to crack with current technology.⁵

3. Versatility. SSH is not just for typing commands. It transfers files (SCP/SFTP), forwards ports (tunneling), and serves as the transport layer for tools like Git, Ansible, and rsync.¹

4. Universal availability. SSH comes pre-installed on Linux, macOS, and (since 2018) Windows 10. Every cloud provider supports it. It is the lingua franca of server management.

---

When do we use SSH?

• When managing remote servers — deploying code, reading logs, restarting services, configuring software
• When transferring files securely between machines (using SCP or SFTP)
• When pushing code to Git repositories (GitHub, GitLab, and Bitbucket all support SSH authentication)
• When automating infrastructure — tools like Ansible and Terraform use SSH to configure remote machines
• When you need to access a service behind a firewall by tunneling traffic through an SSH connection
• When setting up CI/CD pipelines that need to deploy to production servers

Rule of thumb

If you need to interact with a remote machine securely — whether to run commands, transfer files, or tunnel traffic — SSH is almost certainly the right tool.

---

How can I think about SSH?

The diplomatic pouch

In international diplomacy, sensitive documents travel in diplomatic pouches — sealed bags that cannot be opened or inspected by anyone except the sender and recipient.

• Your computer is the embassy sending the pouch
• The server is the embassy receiving it
• The SSH tunnel is the diplomatic pouch — sealed and tamper-proof
• Your commands are the documents inside
• The key exchange is the diplomatic agreement that establishes the secure channel
• Key-based authentication is showing your diplomatic credentials to prove you are authorised to send pouches

Anyone can see that a pouch was sent, but nobody can read what is inside.

The bank vault phone

Some bank vaults have a direct phone line between the vault and the manager’s office — no switchboard, no shared line, completely private.

• Your terminal is the manager’s office
• The server is the vault
• The SSH connection is the direct phone line — private and dedicated
• Password authentication is like giving a verbal password over the line
• Key authentication is like the line only activating when the manager presses a physical key that matches the vault’s lock
• Port forwarding is like letting a colleague use the manager’s phone to talk to the vault on their behalf

---

Concepts to explore next

Concept	What it covers	Status
ssh-keys	Key generation, types (RSA, ed25519), key management	stub
ssh-tunneling	Port forwarding, jump hosts, accessing firewalled services	stub
scp-sftp	Transferring files securely over SSH	stub
public-key-cryptography	The mathematical foundation behind SSH authentication	stub

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

---

Check your understanding

Test yourself (click to expand)

1. Explain why SSH was created and what problem it solved compared to Telnet.
2. Name the three phases of an SSH connection and describe what each phase accomplishes.
3. Distinguish between password authentication and key-based authentication. When would you choose one over the other?
4. Interpret this scenario: you connect to a server and SSH shows the warning “REMOTE HOST IDENTIFICATION HAS CHANGED.” What might have happened, and why is this warning important?
5. Connect SSH to the client-server-model: how does an SSH session follow the client-server pattern, and how does it differ from a typical HTTP request-response cycle?

---

Where this concept fits

Position in the knowledge graph

graph TD
    SA[Software Architecture] --> CSM[Client-Server Model]
    CSM --> SSH[SSH]
    CSM --> HTTP[HTTP Protocol]
    SSH --> SK[SSH Keys]
    SSH --> ST[SSH Tunneling]
    SSH --> SF[SCP / SFTP]
    style SSH fill:#4a9ede,color:#fff

Related concepts:

• client-server-model — SSH is a client-server protocol; the SSH client connects to an SSH daemon (server) listening on port 22
• apis — while APIs define how software components talk to each other, SSH defines how humans and tools securely talk to machines

---

Sources

---

Further reading

Resources

• What is SSH? (Cloudflare) — Clear, beginner-friendly overview of what SSH is and why it matters
• Understanding the SSH Encryption and Connection Process (DigitalOcean) — Deep technical walkthrough of how SSH negotiates encryption
• SSH Protocol (Red Hat) — Authoritative reference covering SSH architecture, configuration, and usage
• SSH Key Best Practices for 2025 (Brandon Checketts) — Practical guide to modern key generation and management
• Secure Shell (Wikipedia) — Comprehensive history and technical specification of the SSH protocol

Footnotes

1. Cloudflare. What is SSH? | Secure Shell (SSH) protocol. Cloudflare Learning Center. ↩ ↩² ↩³ ↩⁴

2. Wikipedia contributors. Secure Shell. Wikipedia. ↩ ↩²

3. DigitalOcean. Understanding the SSH Encryption and Connection Process. DigitalOcean Community Tutorials. ↩ ↩²

4. phoenixNAP. How Does SSH Work?. phoenixNAP Knowledge Base. ↩

5. Checketts, B. (2025). SSH Key Best Practices for 2025. Brandon Checketts. ↩