SSH and FTP

[!NOTE] This module explores the core principles of SSH and FTP, deriving solutions from first principles and hardware constraints to build world-class, production-ready expertise.

1. The Real-World Scenario

Imagine you need to send a highly confidential document to a colleague in another building.

  • FTP (File Transfer Protocol) is like writing the document on a postcard and handing it to a courier. Anyone who touches the postcard along the way can read your secrets.
  • SSH (Secure Shell) is like putting the document in a reinforced, lockbox, hiring an armored truck, and establishing a secret handshake with the receiver before handing it over.

In the modern internet, where packet sniffing is trivial, sending anything unencrypted is a critical security flaw.

2. SSH (Secure Shell)

SSH is a cryptographic network protocol for operating network services securely over an unsecured network. It is the gold standard for remote management of servers.

  • Port: 22 (TCP).
  • Key Features:
  • Encryption: All traffic between client and server is encrypted. Interestingly, SSH uses Asymmetric encryption only to securely agree upon a shared key, and then switches to Symmetric encryption (like AES) for the rest of the session because it is significantly faster for bulk data.
  • Authentication: Password or Public-key based. Public-key cryptography (using an SSH key pair) is highly recommended as it prevents brute-force credential stuffing attacks.
  • Data Integrity: Uses MACs (Message Authentication Codes) like HMAC-SHA256 to ensure packets are not tampered with or modified in transit.

The Anatomy of an SSH Connection

Let’s break down exactly what happens when you type ssh user@remote_server:

  1. TCP Handshake: A standard 3-way TCP handshake establishes a connection on Port 22.
  2. Version Negotiation: The client and server exchange their supported SSH protocol versions (e.g., SSH-2.0-OpenSSH_8.2p1) to ensure compatibility.
  3. Key Exchange (KEX): This is the magic step. Using algorithms like Diffie-Hellman (DH), the client and server exchange public mathematical values to independently derive the exact same shared secret key, without ever sending the secret itself over the network.
  4. User Authentication: Now that a secure, encrypted tunnel exists, the client proves their identity. If using an SSH key pair, the server sends a random challenge encrypted with the user’s public key (stored in ~/.ssh/authorized_keys). The client decrypts it using their private key and sends it back.
  5. Secure Channel: The session begins! All keystrokes and terminal outputs are now encrypted symmetrically using the shared secret from Step 3.

Deep Dive: SSH Tunneling (Port Forwarding)

SSH isn’t just for terminal access; it’s a secure pipe. You can “tunnel” other unencrypted protocols through an SSH connection to secure them or bypass firewalls.

  • Local Port Forwarding (-L): Forwards a port from your local machine to a remote destination.
    • Example: You are running a database on a remote server that only allows localhost access (Port 5432).
    • ssh -L 5432:localhost:5432 user@server allows you to connect to localhost:5432 on your laptop, and the traffic is tunneled to the server’s local database.
  • Dynamic Port Forwarding (-D): Turns your SSH client into a SOCKS proxy, routing all traffic from your browser through the remote server.

3. Interactive: SSH Key Exchange

See how the server is verified and the authentication flow progresses.

💻
Client
↔
Remote Server
SHA256: 4f1a...
Waiting for command...

4. FTP (File Transfer Protocol)

FTP is a legacy, text-based protocol used to move files between a client and a server.

  • Port: 21 (Command/Control), 20 (Data - Active Mode).
  • The Flaw: It is completely Unencrypted. Your username, password, and file contents are sent in plaintext over the wire. If someone uses Wireshark on the same coffee shop Wi-Fi network, they can read everything.

Active vs. Passive FTP (The NAT Problem)

FTP is notorious for being a “Firewall Killer” because it uses two separate channels.

  • Active Mode (The Firewall Nightmare):
    1. Client connects to Server Port 21 and says, “I am listening on my Port 5000 for data.”
    2. The Server initiates a new connection from its Port 20 to the Client’s Port 5000 to send the file.
    3. The Problem: The client’s NAT router or firewall sees an unsolicited, incoming connection attempt from the server and immediately blocks it.
  • Passive Mode (PASV - The Modern Standard):
    1. Client connects to Server Port 21 and requests Passive mode.
    2. The Server opens a random high port (e.g., 50000) and tells the client, “Connect to me on Port 50000 for data.”
    3. The Client initiates the second connection to Server Port 50000.
    4. The Solution: Because both connections are outbound from the client’s perspective, client-side firewalls and NAT seamlessly allow the traffic.

The Secure Alternatives (Always use these instead of FTP)

Never use plain FTP in production.

  1. SFTP (SSH File Transfer Protocol): Not to be confused with “Secure FTP” (FTPS, which is FTP over SSL/TLS). SFTP is an entirely different protocol that runs inside a secure SSH session. It provides full file system access, transfer, and management capabilities, completely secured by SSH encryption.
  2. SCP (Secure Copy Protocol): A simpler CLI tool designed solely for copying files over SSH (e.g., scp ./local.txt user@server:/var/www/). Note: SCP is considered deprecated by OpenSSH in modern systems in favor of SFTP due to underlying protocol rigidities, though it remains widely used.