Linux Telnet & FTP vs Modern Secure Protocols (SSH, SFTP & FTPS) Tutorial

A security and architectural comparison explaining why cleartext protocols were deprecated, packet sniffing vulnerabilities, Active vs Passive FTP modes, and secure encrypted alternatives.

During the early decades of the ARPANET and nascent Internet, protocols were engineered under the assumption that connected computer hosts were operated by trusted academic or government researchers. Two foundational protocols born in that era were Telnet (RFC 854, 1983) for remote terminal login and FTP (File Transfer Protocol, RFC 959, 1985) for transferring files.

However, both protocols suffer from a fatal security vulnerability: they transmit all authentication credentials, usernames, passwords, and session data across the network in unencrypted cleartext. In this masterclass, we examine why modern security standards prohibit Telnet and plain FTP in production, how packet sniffers harvest plaintext credentials, and how to utilize encrypted modern standards: SSH (Secure Shell), SFTP, and FTPS.

1. The Fatal Flaw: Cleartext Packet Sniffing

When an administrator logs into a server using Telnet (TCP port 23) or logs into an FTP server (TCP port 21), every keystroke and packet payload travels across the network in ASCII plaintext. Any adversary connected to the same local switch, public Wi-Fi network, or intermediate router can capture the root credentials in real time using tcpdump:

# Capturing cleartext FTP passwords on port 21 using tcpdump
sudo tcpdump -i eth0 -A 'tcp port 21' | grep -iE 'USER|PASS'

# Example real sniffed output on an unencrypted FTP session:
# USER admin
# PASS SuperSecretPassword2026!

Because there is no cryptographic signature or SSL/TLS tunnel, attackers can perform Man-in-the-Middle (MITM) attacks, eavesdrop on private intellectual property, and hijack active sessions.

2. Side-by-Side Comparison: Insecure vs Modern Secure Protocols

3. The Legacy Role of Telnet Today: Port & Socket Diagnostics

While nobody uses Telnet for remote administration today, the Telnet client binary remains a lightweight tool to test whether a remote TCP port is alive and accepting connections without needing a full application client:

# 1. Test if a remote web server is listening on port 80
telnet example.com 80
# Output: Connected to example.com.
# Escape character is '^]'.

# 2. Test if a remote mail server is listening on SMTP port 25
telnet mail.example.com 25
# Type: QUIT to disconnect

# 3. Modern superior diagnostic tool: Netcat (nc)
nc -zvw3 example.com 80
# Output: Connection to example.com 80 port [tcp/http] succeeded!

4. Anatomy of FTP: Active Mode vs Passive Mode

Unlike modern protocols that operate over a single TCP connection, FTP uses two separate connections: a Control Connection (Port 21) for commands and authentication, and a Data Connection for moving file contents and directory listings:

Active FTP Mode (Standard PORT)

1. Client connects from random port $N$ to Server port 21 (Control Channel).
2. When data needs to be transferred, the client sends the PORT command telling the server: "Connect to my port $N+1$".
3. The Server initiates an inbound connection from port 20 back to client port $N+1$.
4. The Fatal Firewall Problem: Client firewalls, NAT routers, and cloud security groups block the server's unsolicited inbound connection, breaking the file transfer!

Passive FTP Mode (PASV Mode)

1. Client connects from random port $N$ to Server port 21 (Control Channel).
2. Client sends the PASV command requesting a passive connection.
3. The Server opens an unprivileged ephemeral port (e.g. 50000) and tells the client to connect to it.
4. The Client initiates the outbound data connection to the server's port. Because client firewalls allow outbound traffic, Passive Mode works smoothly behind NAT.

5. The Secure Modern Standards: SSH & SFTP

The SSH File Transfer Protocol (SFTP) is built into OpenSSH. If your server allows SSH logins, SFTP is already installed and fully operational without configuring additional daemons:

# 1. Connect to remote server using SFTP
sftp username@192.168.1.100

# 2. Inside the interactive SFTP prompt:
sftp> pwd                   # Print working directory on remote server
sftp> lpwd                  # Print local working directory on your client machine
sftp> ls                    # List remote files
sftp> lls                   # List local files
sftp> put report.pdf        # Upload local file to remote server
sftp> get database_dump.sql # Download remote file to local machine
sftp> exit                  # Disconnect

High-Speed Secure File Copy with rsync over SSH

For synchronization and production backups, rsync utilizes SSH encryption with differential delta transfers:

# Sync local website folder to remote server securely over SSH
rsync -avz -e ssh /var/www/html/ user@192.168.1.100:/var/www/html/

6. Tutorial: Hardening FTP with vsftpd & TLS Encryption (FTPS)

If an enterprise legacy system strictly mandates an FTP service, you must secure it using vsftpd (Very Secure FTP Daemon) enforced with TLS encryption:

# 1. Install vsftpd
sudo apt install vsftpd -y      # Ubuntu/Debian
# sudo dnf install vsftpd -y   # RHEL/Rocky

# 2. Generate a self-signed TLS/SSL Certificate
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout /etc/ssl/private/vsftpd.key \
  -out /etc/ssl/certs/vsftpd.crt

# 3. Configure vsftpd to mandate TLS encryption
sudo nano /etc/vsftpd.conf

Append the following hardening parameters to /etc/vsftpd.conf:

# Enable SSL/TLS encryption
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1_2=YES
ssl_tlsv1_3=YES

# Certificate paths
rsa_cert_file=/etc/ssl/certs/vsftpd.crt
rsa_private_key_file=/etc/ssl/private/vsftpd.key

# Passive mode port range (open these in your firewall!)
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100

# 4. Restart the service and verify
sudo systemctl restart vsftpd
sudo systemctl enable vsftpd

7. Practical Terminal Lab: Verifying Encryption

# 1. Connect to FTPS using an SSL/TLS aware client like curl
curl --insecure --ssl-reqd --user "username:password" ftp://192.168.1.100/

# 2. Verify that plain unencrypted connections are rejected:
ftp 192.168.1.100
# Output: 530 Non-anonymous sessions must use encryption.

8. Student Viva & Exam Practice Q&A

9. Frequently Asked Questions (FAQ)