Understanding SSH: A Beginner's Guide

Source: Dev.to

What Exactly Is SSH?

SSH stands for Secure Shell. It’s a cryptographic network protocol that lets you:

• Log into remote computers securely
• Execute commands on machines you can’t physically touch
• Transfer files without anyone snooping
• Create encrypted tunnels for other network traffic

When you hear “I’ll SSH into the server,” someone is saying they’re about to securely connect to a remote machine and control it through the command line.

Why SSH Was Invented

Before SSH existed, system administrators used tools that transmitted data in clear text:

Example of insecure transmission

USER: admin
PASS: supersecret123

Anyone on the same network could run a packet sniffer and read the credentials.

In the 1990s, a Finnish researcher created SSH after his university network was attacked and passwords were sniffed directly off the wire. SSH was born from a real security incident, not theoretical paranoia.

Analogy: Telnet is like shouting your bank PIN across a crowded room. SSH is like whispering it through an encrypted radio that only you and the bank can decode.

SSH Protocol Versions

SSH‑2 is a complete rewrite with:

• Better key exchange algorithms
• Improved integrity checking
• Support for multiple authentication methods in one session

Always ensure your systems use SSH‑2. Most modern systems do by default, but legacy systems might not.

How SSH Actually Works

Phase 1: TCP Connection

SSH runs over TCP, typically on port 22. The client initiates a standard TCP handshake:

Client → Server: SYN
Server → Client: SYN‑ACK
Client → Server: ACK

Connection established. Now the SSH protocol begins.

Phase 2: Protocol Version Exchange

Both sides announce their SSH version:

Client: SSH-2.0-OpenSSH_8.9
Server: SSH-2.0-OpenSSH_8.4

If either side only supports SSH‑1, modern clients will (and should) refuse to connect.

Phase 3: Key Exchange (The Magic)

The goal is to create a shared secret key that no eavesdropper can know. The most common algorithm is Elliptic Curve Diffie‑Hellman (ECDH):

########### Key Exchange (Simplified) ###########

1. Client and Server agree on mathematical parameters
2. Client generates: private value (a), public value (A)
   Server generates: private value (b), public value (B)
3. They exchange public values (A and B)   [Attacker can see A and B]
4. Client computes: shared_secret = B^a
   Server computes: shared_secret = A^b   [Both arrive at the SAME secret!]
5. This shared secret derives the session encryption keys

The shared secret is never transmitted; an attacker watching every packet still can’t compute it.

Phase 4: Server Authentication (Host Keys)

Before you authenticate to the server, the server authenticates to you. On first connection you’ll see:

The authenticity of host 'server.com (192.168.1.100)' can't be established.
ED25519 key fingerprint is SHA256:AbCdEf1234567890...
Are you sure you want to continue connecting (yes/no/[fingerprint])?

If you type yes, the fingerprint is saved to ~/.ssh/known_hosts. Future connections verify that the server’s key matches the saved fingerprint.

If the fingerprint changes, SSH warns you:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Pro tip: Verify the fingerprint through an out‑of‑band channel (e.g., provider documentation) on first use.

Phase 5: User Authentication

SSH supports several authentication methods.

Method 1: Password Authentication

ssh user@server.com
# Prompts for password

Simple, but not recommended because passwords can be brute‑forced, are vulnerable to keyloggers, and require manual entry each time.

Method 2: Public‑Key Authentication (Preferred)

Uses asymmetric cryptography (a key pair).

How it works

The private key never leaves your machine; the server only sees proof that you have it.

Method 3: Certificate‑Based Authentication

Used in enterprise environments. A Certificate Authority (CA) signs user keys, and servers trust the CA rather than individual keys.

Phase 6: Encrypted Session

After authentication, all traffic is encrypted using symmetric encryption (AES‑256, ChaCha20, etc.). Symmetric ciphers are ~1000× faster than asymmetric ones.

Each packet also includes a MAC (Message Authentication Code)—a cryptographic checksum that detects tampering.

SSH Key Types

Generate a new key pair (ED25519 example):

ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -C "your_email@example.com"

• -a 100 increases the number of KDF (key‑derivation function) rounds, making brute‑force attacks on the private key harder.
• -C adds a comment (often your email) to identify the key.

Common SSH Commands

Securing Your SSH Server

1. Disable SSH‑1 – ensure Protocol 2 is set in /etc/ssh/sshd_config.
2. Enforce public‑key authentication – set PasswordAuthentication no.
3. Change the default port (optional) – e.g., Port 2222.
4. Limit users – AllowUsers alice bob.
5. Use Fail2Ban or similar – block repeated failed login attempts.
6. Enable two‑factor authentication – e.g., Google Authenticator PAM module.
7. Keep OpenSSH up‑to‑date – security patches are released regularly.

Troubleshooting Tips

• “Permission denied (publickey)” – Verify that the public key is correctly placed in ~/.ssh/authorized_keys on the server and that file permissions are restrictive (chmod 600 ~/.ssh/authorized_keys).
• Host key verification failed – Remove the old entry from ~/.ssh/known_hosts (ssh-keygen -R hostname) and reconnect.
• Connection timed out – Ensure port 22 (or your custom port) is open in firewalls and that the server’s SSH daemon is running.
• Slow login – Check DNS reverse‑lookup settings; add UseDNS no in sshd_config if DNS lookups are causing delays.

Further Reading

• OpenSSH Manual
• RFC 4251 – The Secure Shell (SSH) Protocol Architecture
• SSH, The Secure Shell: The Definitive Guide by Daniel J. Barrett, Richard E. Silverman, and Robert G. Byrnes

This guide provides a concise overview of SSH fundamentals, how the protocol works, and best practices for secure usage.