How SSH works, with practical context

🔒 What SSH Is (and Why It Matters)

SSH (Secure Shell) is a protocol used to securely access and control remote computers over a network.

Instead of sending data in plain text (like Telnet), SSH:

Encrypts everything
Protects passwords
Secures commands and file transfers
Prevents eavesdropping and tampering

It is the modern secure replacement for older remote login tools.

🚪 Step 1: The Connection (Port 22)

By default:

SSH runs on TCP port 22
The SSH client connects to an SSH server (running sshd)
Once connected, a secure tunnel is created

Firewalls often allow port 22 for administrative access.

🔑 Step 2: Cryptography – How the Secure Tunnel Is Built

SSH uses multiple layers of cryptography.

1️⃣ Asymmetric Cryptography (Key Exchange)

When you connect:

Client and server negotiate encryption algorithms
They perform a key exchange (often ECDH or Diffie–Hellman)
They generate a shared secret

Important:

The shared secret is never transmitted
Both sides compute it independently
This protects against interception

2️⃣ Symmetric Encryption (Session Phase)

After the shared secret is created:

A session key is derived
All data is encrypted using fast symmetric encryption (like AES)

Why symmetric?

Much faster than asymmetric
Efficient for continuous data transfer

So:

🔐 Asymmetric → Securely establish trust
⚡ Symmetric → Efficiently encrypt the session

🧩 Step 3: The SSH Handshake (Simplified Flow)

Client connects to server
Exchange protocol versions
Negotiate encryption algorithms
Perform key exchange
Derive session key
Switch to encrypted mode
Only then → authentication begins

Important:
The login prompt appears after encryption is already active.

👤 Step 4: Authentication

SSH supports two main authentication methods:

🔑 Password Authentication (Basic)

User types password
Password travels encrypted inside the SSH tunnel
Still vulnerable to brute-force attempts

🗝️ SSH Key Authentication (Recommended)

Much stronger and preferred.

You generate:

Private key → stays on your computer
Public key → copied to the server

The server stores the public key in:

~/.ssh/authorized_keys

During login:

Server sends a challenge
Client signs it using the private key
Server verifies using the public key
Access granted

No password is transmitted.

☁️ Real-World Example: AWS EC2

With Amazon Web Services (AWS):

You create a key pair
AWS gives you a .pem private key
AWS inserts the public key into the instance

You connect with:

ssh -i mykey.pem ec2-user@server-ip

⚠ If someone steals your .pem file, they can access the server.

📦 Real-World Example: GitHub Over SSH

With GitHub:

You upload your public key to your account
Git operations use SSH authentication
GitHub verifies your private key signature

GitHub does not allow password-based Git over SSH.

🛠️ SSH Port Forwarding (Tunneling)

SSH can securely forward traffic.

Example:

You have:

A private MySQL database inside a secure network
A public SSH bastion server

You create:

ssh -L 3306:internal-db:3306 user@bastion

Now:

Your local machine’s localhost:3306
Securely tunnels to the internal database
All traffic is encrypted

This allows secure access without exposing the database publicly.

🧠 Why Ephemeral Session Keys Matter

Each SSH session:

Generates a fresh key
Uses temporary encryption
Cannot be reused later

This provides forward secrecy:
Even if long-term keys are compromised later, past sessions remain secure.

🔐 Security Takeaways

✔ SSH encrypts everything
✔ Encryption starts before authentication
✔ Key-based login is more secure than passwords
✔ Session keys are temporary
✔ Port forwarding allows secure internal access
✔ Disable password auth in production environments

🏢 Practical Advice (Org-Level)

If managing servers, storage systems, or remote Linux machines:

Use key-based authentication only
Disable root login
Restrict SSH by firewall IP rules
Monitor failed login attempts
Rotate keys when staff leave