FTP, SSH, and Telnet Explained: File Transfer and Remote Access Protocols

Moving files between systems and remotely controlling servers are fundamental IT operations that happen thousands of times daily in every organization. Three protocols have historically dominated these tasks: FTP for file transfers, SSH for secure remote access, and Telnet for command-line control. Understanding these protocols—particularly their security implications and modern alternatives—is essential for IT professionals and CompTIA A+ certification candidates.

While FTP remains widely recognized, its security vulnerabilities have pushed organizations toward encrypted alternatives like SFTP and FTPS. SSH has become the gold standard for secure remote administration, and Telnet has been relegated to deprecated status due to its fundamental insecurity. This guide explores each protocol, their ports, practical usage scenarios, and critical security considerations.

Reading Time: 15 minutes

What You’ll Learn:

• FTP (File Transfer Protocol) and its security limitations
• Secure alternatives: SFTP and FTPS with encryption
• SSH (Secure Shell) for encrypted remote access
• Telnet’s deprecated status and security risks
• Port numbers: 21 (FTP), 22 (SSH), 23 (Telnet), 989/990 (FTPS)
• Practical configuration with FileZilla and PuTTY
• When to use each protocol in modern environments
• How to check and disable insecure protocols

Prerequisites: Basic networking knowledge and familiarity with command-line interfaces helpful but not required.

FTP: File Transfer Protocol

FTP (File Transfer Protocol) enables computers to transfer files bidirectionally when connected to an FTP server, providing a standardized method for uploading and downloading files across networks.

How FTP Works

Basic FTP connection flow:

1. Client initiates: FTP client connects to FTP server
2. Server listens: FTP server has port 21 open (control connection)
3. Authentication: User provides username and password
4. Command channel: Client sends commands over port 21
5. Data transfer: Separate data connection established (port 20 or random high port)
6. File operations: Upload (PUT), download (GET), list directory, delete, rename
7. Disconnection: Client terminates session

FTP connection modes:

Active FTP:

• Client opens random port, tells server via port 21
• Server initiates data connection from port 20 to client’s port
• Problematic with firewalls (server connecting to client)

Passive FTP:

• Client requests passive mode
• Server opens random high port for data
• Client initiates both control and data connections
• Firewall-friendly (client initiates everything)

FTP Port Numbers

Port 21: Control Connection

• Command channel for FTP operations
• Authentication occurs here
• Directory listings and commands transmitted
• Remains open during entire session

Port 20: Data Connection (Active Mode)

• Used in active FTP mode
• Server initiates connection from port 20
• Rarely used in modern networks due to firewall issues

Random High Ports: Data Connection (Passive Mode)

• Used in passive FTP mode (modern default)
• Server listens on negotiated port (typically 1024-65535)
• Client connects to this port for data transfer

FTP Clients and Access Methods

Command-line FTP (Built into Windows/Linux/macOS):

Accessing FTP shell:

textftp

This launches the FTP command-line interface.

Connecting to FTP server:

textftp> open davidlprouse.com

Expected interaction:

textConnected to davidlprouse.com.
220 Welcome to davidlprouse.com FTP server
User (davidlprouse.com:(none)): test@davidlprouse.com
331 Password required for test
Password: ********
230 User test logged in
ftp> 

Current directory status:

text230 Current restricted directory is /

This indicates you’re in the root directory for this user account (restricted, not system root).

Common FTP commands:

textftp> ?                    # Display all available commands
ftp> ls                   # List files in current directory
ftp> cd directory_name    # Change directory
ftp> get filename         # Download file from server
ftp> put filename         # Upload file to server
ftp> delete filename      # Delete file on server
ftp> mkdir folder_name    # Create directory
ftp> pwd                  # Print working directory
ftp> bye                  # Disconnect and exit

GUI FTP Clients:

FileZilla (Free and Pro versions):

• Cross-platform (Windows, macOS, Linux)
• Visual drag-and-drop interface
• Queue management for multiple transfers
• Site Manager for saving connection profiles
• Supports FTP, FTPS, and SFTP

Other popular FTP clients:

• WinSCP (Windows, free)
• Cyberduck (macOS, Windows)
• Transmit (macOS, commercial)
• CuteFTP (Windows, commercial)
• Core FTP (Windows, free)

FileZilla Connection Example

Connection details displayed in FileZilla:

textStatus: Connecting to 216.97.236.245:21...
Status: Connection established, waiting for welcome message...
Response: 220 Welcome to FTP Server
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established
Command: USER test@davidlprouse.com
Response: 331 Password required
Command: PASS ********
Response: 230 User logged in
Status: Connected

What’s happening:

1. Initial connection to port 21 (FTP control)
2. Server sends welcome message
3. TLS encryption initialized (upgrading security)
4. Certificate verification (authenticating server identity)
5. Username and password authentication
6. Successful login and file transfer ready

Important observation: FileZilla connected to port 21 but then initialized TLS encryption, converting the session to FTPS (FTP Secure).

The Critical Security Problem with Standard FTP

FTP is fundamentally insecure because:

1. Unencrypted credentials:

• Usernames and passwords transmitted in plain text
• Anyone intercepting traffic can capture login credentials
• Passwords visible in packet captures (Wireshark, tcpdump)

2. Unencrypted data:

• All file contents transmitted without encryption
• Sensitive documents readable during transmission
• Intellectual property exposed to eavesdropping

3. Session hijacking:

• Active FTP connections vulnerable to hijacking
• Attackers can inject commands mid-session
• No integrity verification of commands

4. No server authentication:

• Client can’t verify server identity
• Vulnerable to man-in-the-middle attacks
• Spoofed FTP servers can capture credentials

Real-world risk: On public Wi-Fi networks or compromised networks, attackers trivially capture FTP credentials and file contents using freely available tools.

⚠️ Security Recommendation: Never use standard FTP for sensitive data or in untrusted network environments. Organizations should disable standard FTP entirely and use secure alternatives exclusively.

FTPS: FTP Secure

FTPS (File Transfer Protocol Secure) adds SSL/TLS encryption to standard FTP, protecting credentials and data during transmission while maintaining FTP’s familiar functionality.

How FTPS Works

FTPS wraps FTP communication in TLS encryption:

1. Initial connection: Client connects to FTP server
2. TLS negotiation: Client and server negotiate encryption
3. Certificate exchange: Server presents SSL/TLS certificate
4. Encrypted channel: All FTP commands and data transmitted through encrypted tunnel
5. File transfer: Files encrypted during upload/download
6. Secure session: Authentication and data protected

FTPS Port Numbers

Port 989: FTPS Data Connection

• Encrypted data channel
• File contents transferred through TLS

Port 990: FTPS Control Connection

• Encrypted command channel
• Authentication and commands protected

Implicit vs Explicit FTPS:

Implicit FTPS (port 990):

• Encryption required from initial connection
• Client must support TLS from start
• Older method, less flexible
• Connection fails if TLS unavailable

Explicit FTPS (port 21):

• Connects to standard port 21 initially
• Client issues AUTH TLS command to upgrade
• Falls back to unencrypted if TLS unavailable (configurable)
• More flexible, widely supported

Modern recommendation: Use explicit FTPS connecting to port 21 with mandatory TLS upgrade (as shown in FileZilla example earlier).

FTPS Advantages

Security improvements over FTP:

• ✅ Encrypted credentials (username/password protected)
• ✅ Encrypted data transfer (file contents protected)
• ✅ Server authentication (SSL/TLS certificates verify identity)
• ✅ Data integrity (tampering detected)

Compatibility:

• Works with standard FTP clients (if TLS-capable)
• Similar commands and workflow to FTP
• Easy migration from FTP infrastructure
• Same familiar interface for users

When to use FTPS:

• Organizations with existing FTP infrastructure wanting to add encryption
• Environments requiring SSL/TLS compliance
• Scenarios where SSH unavailable
• Legacy systems unable to run SFTP

💡 FTPS vs SFTP: FTPS adds encryption to FTP protocol, while SFTP is completely different (runs over SSH). Both provide security but use different underlying technologies.

SSH: Secure Shell

SSH (Secure Shell) enables encrypted data exchange between computers over a secured channel, providing remote command-line access and secure file transfer capabilities.

How SSH Works

SSH connection establishment:

1. Client initiates: SSH client connects to server port 22
2. Version negotiation: Client and server agree on SSH protocol version
3. Key exchange: Cryptographic keys exchanged using Diffie-Hellman
4. Server authentication: Client verifies server’s host key (prevents MITM)
5. Client authentication: User authenticates (password, public key, or certificate)
6. Encrypted channel: Secure tunnel established for all communication
7. Session: Remote command execution or file transfer over encrypted channel

SSH Port Number

Port 22: SSH Default

• All SSH communication uses this port
• Command sessions (remote terminal access)
• File transfers (SFTP)
• Port forwarding and tunneling
• Must be open on server firewall for SSH access

SSH Authentication Methods

1. Password Authentication:

• Traditional username/password
• Simpler but less secure
• Vulnerable to brute force (if weak passwords)
• Should be supplemented with fail2ban or similar protections

2. Public Key Authentication:

• Uses asymmetric cryptography
• Private key stays on client (protected by passphrase)
• Public key uploaded to server
• No password transmitted over network
• More secure (immune to password guessing)
• Recommended for production systems

3. Certificate-Based Authentication:

• SSH certificates signed by trusted CA
• Centralized key management
• Fine-grained access control
• Enterprise-scale authentication

SSH Use Cases

Remote server administration:

• Command-line access to Linux/Unix servers
• Execute administrative commands remotely
• Monitor system logs and performance
• Install software and manage services

Secure file transfer (SFTP):

• Transfer files over encrypted SSH connection
• Replaces insecure FTP
• Same functionality as FTP with encryption
• Uses port 22 (no additional ports needed)

SSH tunneling (port forwarding):

• Encrypt otherwise insecure protocols
• Access internal services through SSH tunnel
• VPN-like functionality for specific ports
• Bypass firewall restrictions (legitimate use)

Remote command execution:

• Run single commands without interactive login
• Automated scripts and system administration
• Backup operations
• Deployment automation

PuTTY: SSH Client for Windows

PuTTY is the most popular free SSH client for Windows, providing terminal access to remote systems.

PuTTY Configuration Example:

Scenario: Connecting from Windows to Linux server via SSH

PuTTY setup:

1. Launch PuTTY application
2. Session configuration:
   • Host Name (or IP address): 192.168.1.50 (Linux server IP)
   • Port: 22
   • Connection type: SSH
3. Click “Open”

Connection sequence:

textlogin as: administrator
administrator@192.168.1.50's password: ********
Welcome to Ubuntu 22.04.3 LTS
Last login: Thu Dec 11 10:30:15 2025 from 192.168.1.100
administrator@linuxserver:~$ 

Now you have command-line control of the remote Linux server from Windows:

bashadministrator@linuxserver:~$ ls -la
administrator@linuxserver:~$ df -h
administrator@linuxserver:~$ sudo systemctl status apache2
administrator@linuxserver:~$ exit

PuTTY features:

• Session management: Save connection profiles
• Port forwarding: Configure SSH tunnels
• X11 forwarding: Run remote GUI applications
• Serial connection: Access devices via COM ports
• Logging: Record session output

Alternative SSH clients:

• Windows 10/11 built-in: OpenSSH client (command-line: ssh user@server)
• Terminal (Windows 11): Modern terminal with SSH support
• MobaXterm: Enhanced SSH client with X server
• SecureCRT: Commercial SSH client with advanced features

SFTP: Secure File Transfer Protocol

SFTP (SSH File Transfer Protocol) provides secure file transfer over SSH, completely replacing insecure FTP.

Key distinction: SFTP is NOT “Secure FTP”—it’s a completely different protocol that runs over SSH (port 22), unrelated to FTP/FTPS.

How SFTP differs from FTP:

SFTP advantages:

Superior security:

• Always encrypted (no unencrypted option exists)
• Strong cryptography (same as SSH)
• Public key authentication available
• No cleartext credentials possible

Firewall simplicity:

• Single port (22) for everything
• No active/passive mode complications
• Easier firewall rule configuration
• NAT-friendly (single connection)

Reliability:

• Connection persistence
• Resume interrupted transfers
• Better error handling
• File locking support

SFTP client support:

FileZilla: Supports SFTP natively

• Select “SFTP” protocol in connection settings
• Uses port 22 automatically
• Requires SSH server on remote system

WinSCP: Windows SFTP specialist

• Defaults to SFTP protocol
• Excellent for Windows-to-Linux transfers
• Commander-style dual-pane interface

Command-line SFTP:

bashsftp user@server.com
sftp> ls
sftp> get remotefile.txt
sftp> put localfile.txt
sftp> bye

Industry adoption: Most organizations have migrated from FTP/FTPS to SFTP due to superior security and simplicity.

🏢 Corporate Standard: Publishing companies, web hosts, and software distributors typically require SFTP for file submissions. Many explicitly prohibit FTP due to security policies.

Telnet: The Deprecated Protocol

Telnet (Telecommunications Network) provides remote command-line access to hosts but is considered fundamentally insecure and deprecated due to complete lack of encryption.

How Telnet Works

Telnet connection:

1. Client connects: Telnet client contacts server port 23
2. Authentication: Username and password prompted
3. Plain text session: All communication unencrypted
4. Command execution: Remote terminal access to host
5. Session: Interactive command-line control

The fatal security flaw: Everything transmitted in plain text—credentials, commands, and output completely visible to network eavesdroppers.

Telnet Port Number

Port 23: Telnet Default

• Standard Telnet service port
• Should be closed on modern systems
• Firewall rules should block external port 23 access
• No legitimate reason to expose port 23 to internet

Why Telnet is Insecure

Security vulnerabilities:

1. Unencrypted credentials:

textUsername: administrator
Password: P@ssw0rd123

Both transmitted in plain text, captured by packet sniffers.

2. Unencrypted commands:

textcd /etc
cat /etc/shadow

Every command visible to network observers.

3. Unencrypted output:
All command results, sensitive data, and system information transmitted without protection.

4. No server authentication:
Client can’t verify server identity—spoofed Telnet servers capture credentials.

5. Session hijacking:
Active sessions can be hijacked and controlled by attackers.

Attack scenario: On public Wi-Fi, attacker runs Wireshark, filters for port 23 traffic, immediately sees all Telnet credentials and commands in plain text.

Limited Legitimate Uses for Telnet

Despite security flaws, Telnet occasionally serves specific purposes:

1. Testing network connectivity:

texttelnet google.com 80

Tests if port 80 is reachable (HTTP service accessible).

Expected response:

textTrying 142.250.185.46...
Connected to google.com.
Escape character is '^]'.

This confirms network connectivity and port accessibility without making HTTP requests.

2. Testing specific services:

texttelnet mail.example.com 25

Tests SMTP server connectivity and banner information.

3. Managing network devices:

• Legacy routers, switches, and network equipment
• Older devices lacking SSH support
• Only on isolated management networks (never over public internet)
• Should be upgraded to SSH-capable equipment

4. Internal troubleshooting:

• Temporary testing on completely isolated networks
• Verify port listeners before implementing secure protocols
• Training and educational environments

⚠️ Critical Warning: Telnet should NEVER be used on production systems, over untrusted networks, or for authentication on any system connected to the internet. SSH replaces every legitimate Telnet use case with encryption.

Checking Telnet Status on Windows

Verifying if Telnet is enabled:

Method 1: Services Console

1. Press Windows + R
2. Type: services.msc
3. Press Enter
4. Scroll to “T” section
5. Look for “Telnet” service

If Telnet disabled (recommended): Service will not appear in list.

If Telnet enabled (check if running):

• Service listed as “Telnet”
• Check Status column (should be blank/stopped)
• Check Startup Type (should be “Disabled”)

Method 2: Windows Features

1. Control Panel → Programs and Features
2. Click Turn Windows features on or off (left sidebar)
3. Scroll to Telnet Client
4. Unchecked = disabled (recommended)
5. Checked = enabled

Disabling Telnet Client:

• Uncheck “Telnet Client”
• Click OK
• Windows removes Telnet functionality
• Requires restart (sometimes)

Default status: Telnet is disabled by default on Windows 10/11 for security reasons.

Temporary disabling: If Telnet service is running but you might need it later, stop it in Services rather than uninstalling the feature.

SSH: The Secure Telnet Replacement

Every Telnet use case is better served by SSH:

Migration path: Replace all Telnet access with SSH immediately. No exceptions for production environments.

Protocol Comparison and Port Summary

Quick Reference Table

Port Number Memory Aids

Sequential protocol ports:

• Port 20/21: FTP (file transfer)
• Port 22: SSH (secure shell)
• Port 23: Telnet (telecommunications)

Secure variants use higher ports:

• Port 989/990: FTPS (near 1000 range)

Remember by relationship:

• FTP (21) → FTPS (989/990): Adding “S” moves to 900s
• Telnet (23) → SSH (22): Secure version is one number lower
• SFTP = SSH port (22): SFTP rides on SSH

Security Assessment

Secure for production:

• ✅ SSH (port 22): Encrypted, modern standard
• ✅ SFTP (port 22): Encrypted file transfer
• ✅ FTPS (port 989/990): Encrypted FTP variant

Insecure – avoid in production:

• ❌ FTP (port 21): Plain text file transfer
• ❌ Telnet (port 23): Plain text remote access

Conditional use:

• ⚠️ FTP with TLS upgrade: Acceptable if mandatory TLS enforced
• ⚠️ Telnet on isolated networks: Only for legacy equipment, never internet-facing

Practical Configuration Examples

Example 1: Secure File Transfer with FileZilla (SFTP)

Scenario: Upload files securely to web server

FileZilla configuration:

1. Launch FileZilla
2. Quick Connect bar:
   • Host: sftp://webserver.example.com
   • Username: webadmin
   • Password: [enter password]
   • Port: 22
3. Click “Quickconnect”

Connection log:

textStatus: Connecting to webserver.example.com:22...
Status: Using SSH protocol version 2
Status: We claim version: SSH-2.0-FileZilla_3.60.2
Status: Server version: SSH-2.0-OpenSSH_8.9p1
Status: Using SSH key exchange algorithm: ecdh-sha2-nistp256
Status: Host key algorithm: ssh-ed25519
Status: Initializing AES-256-CTR encryption
Status: Verified host key
Status: Connected

File transfer:

• Drag files from local (left pane) to remote (right pane)
• All transfers encrypted over SSH
• No additional ports needed
• Resume support for interrupted transfers

Example 2: Remote Server Management with PuTTY (SSH)

Scenario: Administer Linux web server from Windows

PuTTY configuration:

1. Open PuTTY
2. Session settings:
   • Host Name: 192.168.1.100
   • Port: 22
   • Connection type: SSH
3. Optional – Save session:
   • Saved Sessions: Enter name “Web Server”
   • Click Save
4. Click “Open”

SSH session:

textlogin as: admin
admin@192.168.1.100's password: ********

Linux webserver 5.15.0-91-generic #101-Ubuntu SMP
Last login: Thu Dec 11 14:30:00 2025 from 192.168.1.50

admin@webserver:~$ sudo systemctl status apache2
● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled)
     Active: active (running) since Thu 2025-12-11 08:00:00 IST

admin@webserver:~$ tail -f /var/log/apache2/access.log
[monitoring live web server access]

admin@webserver:~$ exit
logout
Connection closed.

Security benefits:

• Encrypted credentials and commands
• Public key authentication (optional, more secure)
• Session cannot be intercepted or hijacked
• Meets security compliance requirements

Example 3: Network Port Testing with Telnet

Scenario: Test if web server port 80 is accessible

Command:

texttelnet webserver.example.com 80

Successful connection:

textTrying 216.97.236.245...
Connected to webserver.example.com.
Escape character is '^]'.

Port is open and accepting connections.

Type HTTP request:

textGET / HTTP/1.1
Host: webserver.example.com
[press Enter twice]

Server responds with HTTP headers and HTML (confirms web server functional).

Failed connection:

textTrying 216.97.236.245...
telnet: connect to address 216.97.236.245: Connection refused
telnet: Unable to connect to remote host

Port 80 is closed or filtered (web server not running or firewall blocking).

Important: This Telnet use doesn’t involve authentication—just connectivity testing. It’s one of the few remaining legitimate Telnet uses.

Security Best Practices

Protocol Selection Guidelines

For file transfers:

• ✅ First choice: SFTP (port 22) – encrypted, simple firewall rules
• ✅ Alternative: FTPS (port 989/990) – if FTP infrastructure exists
• ❌ Never use: Plain FTP (port 21) – unencrypted credentials and data

For remote administration:

• ✅ Always use: SSH (port 22) – encrypted, secure
• ❌ Never use: Telnet (port 23) – completely insecure

Hardening Recommendations

SSH security:

1. Disable password authentication (use keys):

bash# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes

2. Disable root login:

bashPermitRootLogin no

3. Change default port (optional security through obscurity):

bashPort 2222  # Non-standard port reduces automated attacks

4. Limit user access:

bashAllowUsers admin webmaster

5. Use fail2ban to block brute-force:

Automatically bans IPs after failed login attempts.

FTP/FTPS hardening:

1. Require TLS/SSL:

• Configure “require explicit TLS”
• Reject unencrypted connections
• Force certificate validation

2. Restrict user access:

• Chroot users to home directories
• Limit upload/download permissions
• Implement bandwidth throttling

3. Use strong authentication:

• Enforce complex passwords
• Consider certificate authentication
• Implement two-factor where possible

Telnet mitigation:

1. Disable entirely:

• Uninstall Telnet client/server
• Block port 23 at firewall
• Audit for any Telnet usage

2. Migration plan:

• Identify systems using Telnet
• Deploy SSH access
• Educate users on SSH clients
• Remove Telnet from change management

3. Legacy equipment:

• Isolate on management VLAN
• Use jump hosts for access
• Plan hardware upgrades to SSH-capable

Troubleshooting Common Issues

Cannot Connect to FTP Server

Symptoms:

• “Connection refused” errors
• “Connection timed out” errors
• Can ping server but FTP fails

Troubleshooting steps:

1. Verify port 21 accessibility:texttelnet ftp.example.com 21 If connection fails, port is blocked or FTP service down.
2. Check firewall rules:
   • Local firewall (client side)
   • Server firewall (port 21 open?)
   • Network firewall (ISP or corporate blocking?)
3. Test passive mode:
   • Enable passive mode in FTP client
   • Some firewalls block active FTP
4. Verify credentials:
   • Username format (user@domain vs just user)
   • Password correctness
   • Account active and not locked
5. Check FTP service:
   • Server-side: Is FTP service running?
   • Check logs for error messages

SSH Connection Refused

Symptoms:

• “Connection refused” when connecting
• “Host key verification failed”
• “Permission denied”

Troubleshooting:

1. Verify SSH service running:bashsudo systemctl status sshd # Linux
2. Check port 22 accessibility:texttelnet server.com 22 Should show SSH version banner.
3. Firewall verification:
   • Server firewall allows port 22
   • Network firewall not blocking SSH
   • ISP not restricting port 22
4. Host key issues:
   • If key changed: Remove old key from known_hosts
   • Location: ~/.ssh/known_hosts (Linux) or C:\Users\USERNAME\.ssh\known_hosts (Windows)
5. Authentication failures:
   • Verify username correct
   • Check password or private key
   • Ensure public key uploaded to server if using key authentication

SFTP Won’t Connect

Common issue: Using FTP port (21) instead of SSH port (22)

Solution:

text# Wrong
Host: ftp.example.com
Port: 21
Protocol: SFTP

# Correct
Host: ftp.example.com
Port: 22
Protocol: SFTP

SFTP always uses port 22 (SSH), never port 21.

Telnet Command Not Found

Symptom: 'telnet' is not recognized as an internal or external command

Cause: Telnet Client feature disabled (Windows default)

Solution (if legitimately needed):

1. Control Panel → Programs and Features
2. Turn Windows features on or off
3. Check “Telnet Client”
4. Click OK, wait for installation
5. Telnet command now available

Alternative for port testing:
Use PowerShell instead:

powershellTest-NetConnection -ComputerName webserver.com -Port 80

Provides port connectivity testing without enabling deprecated Telnet.

Key Takeaways

🔓 Standard FTP and Telnet are fundamentally insecure because they transmit credentials and data in plain text—both should be considered deprecated protocols and replaced with encrypted alternatives (SFTP/SSH) in all modern environments.

🔐 SSH (port 22) has become the universal secure protocol for both remote administration and file transfer (via SFTP), offering encryption, strong authentication, and firewall-friendly single-port connectivity that makes it the modern standard.

📁 For secure file transfers, choose SFTP over FTPS when possible—SFTP runs over SSH (single port 22), while FTPS requires multiple ports (989/990) and more complex firewall configuration, though both provide adequate encryption.

🛡️ Legacy protocol migration is essential for security compliance—audit your environment for FTP (port 21) and Telnet (port 23) usage, create migration plans to SSH/SFTP, and disable insecure protocols to meet modern security standards.

Frequently Asked Questions

Q: What’s the difference between SFTP and FTPS?
A: SFTP runs over SSH (port 22) and is a completely different protocol from FTP. FTPS is FTP with SSL/TLS encryption added (ports 989/990). Both are secure, but SFTP is simpler (single port) and more commonly used in modern environments.

Q: Can I use FileZilla for SFTP, or only FTP?
A: FileZilla supports FTP, FTPS, and SFTP. When connecting, select “SFTP” protocol and use port 22. The interface looks identical regardless of protocol—only the underlying connection changes.

Q: Is there any legitimate reason to use Telnet in 2025?
A: Very limited uses remain: testing port connectivity (telnet server.com 80), troubleshooting network services, and managing ancient equipment that can’t be upgraded. Never use Telnet for authentication or on production systems. SSH replaces essentially all Telnet uses.

Q: Why does SSH use port 22 while Telnet uses port 23?
A: Historical assignment by IANA. Port numbers don’t indicate relationship—SSH was designed as Telnet’s secure replacement but received a different port number. The fact that 22 comes before 23 is coincidental.

Q: Can I change SSH from port 22 to something else?
A: Yes, SSH can run on any port. Some administrators move SSH to non-standard ports (like 2222 or 22222) to reduce automated attack attempts, but this is “security through obscurity” and shouldn’t replace proper SSH hardening (key authentication, fail2ban, etc.).

Q: Do I need both PuTTY and FileZilla?
A: They serve different purposes. PuTTY provides command-line SSH access for remote administration. FileZilla provides graphical file transfer (SFTP/FTP/FTPS). You typically need both—PuTTY for server management, FileZilla for file uploads/downloads.

Next Steps: Advancing Your Protocol Knowledge

Understanding these protocols prepares you for certification exams and practical system administration.

Recommended learning path:

Week 1-2: Hands-on practice

• Install FileZilla and connect to SFTP servers
• Set up PuTTY connections to SSH servers
• Practice command-line FTP and SFTP
• Configure SSH key authentication

Week 3-4: Server-side configuration

• Install and configure OpenSSH server (Linux)
• Set up FTP/SFTP server (vsftpd, ProFTPD)
• Implement SSL/TLS certificates for FTPS
• Harden SSH configuration

Week 5-6: Security hardening

• Configure fail2ban for SSH protection
• Implement SSH key-only authentication
• Audit and disable Telnet/FTP
• Set up VPN for remote access

Certifications covering these topics:

• CompTIA A+ (220-1101/220-1102): Protocol fundamentals, ports, security
• CompTIA Network+: Advanced protocol operation, troubleshooting
• CompTIA Security+: Secure protocols, encryption, hardening
• Linux+ / LPIC-1: SSH server configuration, SFTP setup

Related Topics:

• “SSH Key Authentication: Complete Setup Guide for Public Key Login”
• “Securing Linux Servers: SSH Hardening and Fail2ban Configuration”
• “Understanding SSL/TLS Certificates for Secure Communications”
• “Network Port Security: Firewall Configuration for Common Protocols”

Have questions about FTP, SSH, or migrating from legacy protocols? Drop a comment below with your specific scenario—I respond to every question and help troubleshoot connectivity issues.

Protocol security isn’t optional in modern IT environments. Understanding the vulnerabilities of FTP and Telnet, embracing SSH and SFTP as secure alternatives, and knowing when and how to use each protocol separates competent IT professionals from those creating security vulnerabilities. Master these fundamentals, implement secure protocols in your infrastructure, and stay current with security best practices!