FTP, SFTP, and FTPS are three different architectures—not three names for the same service
The fastest way to make mistakes is to treat “secure file transfer” as one protocol. FTP is the classic File Transfer Protocol with separate control and data connections. SFTP is SSH File Transfer Protocol and normally runs inside SSH. FTPS is FTP protected with TLS, so it inherits FTP’s control/data architecture even though the transport is encrypted.
Compare the protocols by architecture before comparing ports
| Feature | FTP | SFTP | FTPS |
|---|---|---|---|
| Base protocol | FTP | SSH file-transfer protocol | FTP + TLS |
| Common control/service port | TCP 21 | TCP 22 | Explicit commonly begins on TCP 21; deployments vary |
| Separate data channel? | Yes | No FTP-style separate data channel | Yes, because it remains FTP |
| Transport protection | No equivalent built-in encryption | SSH encryption | TLS encryption |
| Firewall complexity | Control + negotiated data | Usually simpler single SSH service path | Control + negotiated data + TLS |
Swipe horizontally to see the full comparison.
FTP can authenticate successfully while file transfer still fails
FTP commonly uses TCP 21 for the control connection. Commands, authentication, and transfer setup occur over that channel. The actual directory listing or file payload uses a separate data connection. That means “I can log in” proves less than many students assume.
A strong diagnosis preserves control success and moves directly to the data-channel branch.
Active FTP can fail because the server initiates the data connection back toward the client
In classic active FTP, the client establishes the control session, then the server initiates a separate data connection back toward the client using negotiated information. Historically, server TCP 20 is associated with active-mode data behavior.
This reverse-direction connection is exactly what makes active FTP difficult through client-side firewalls and NAT. A client may be able to reach TCP 21 on the server while the server cannot open the return data connection.
Passive mode flips the data-connection initiator, but still needs a server-side port range
In passive FTP, the server tells the client which server-side data port to use and the client initiates that connection. This often works more naturally through client NAT/firewalls, but the server and perimeter policy must allow the configured passive range.
The correct conclusion is not “FTP port 21 is blocked.” TCP 21 already succeeded.
SFTP does not inherit FTP’s two-channel behavior
SFTP operates through SSH, commonly on TCP 22. It is not FTP with an added “S,” and it does not use FTP’s separate control and data connection model. That architectural difference explains why SFTP firewall policy can often focus on the SSH service path rather than negotiated FTP data ports.
FTPS adds TLS but keeps FTP-style transfer mechanics
FTPS protects FTP communication with TLS. Explicit FTPS commonly begins on the FTP control port and negotiates TLS. Implicit FTPS has historically used a separate dedicated service port, but actual deployments should be verified from server configuration.
Because FTPS remains FTP underneath, active/passive data-channel behavior and corresponding firewall/NAT considerations still matter.
Encryption protects transport, but authorization still controls what an authenticated user may do
FTP
Traditional FTP does not provide equivalent encrypted protection for credentials and data on an untrusted path.
SFTP
SSH protects the session. Key-based authentication may be used where configured.
FTPS
TLS protects FTP communication and introduces certificate identity/trust considerations.
None of these transport choices justify broad filesystem permissions, unnecessary shell access, shared accounts, or excessive network exposure.
Protocol choice changes the identity evidence you troubleshoot
SFTP may use SSH passwords, public keys, or other SSH authentication methods. FTPS protects the FTP authentication exchange with TLS and requires certificate handling on the server side. Plain FTP may rely on username/password without equivalent transport protection.
If the network path succeeds but authentication fails, inspect the credential or identity method specific to the protocol instead of changing unrelated routing.
One allow rule can be enough for SFTP while being incomplete for FTP/FTPS
| Protocol | Typical firewall expectation | Common failure pattern |
|---|---|---|
| FTP | Permit control plus required active/passive data behavior | Login works, listing/transfer hangs |
| SFTP | Permit authorized SSH service path | TCP 22/SSH or auth/subsystem failure |
| FTPS | Permit FTP control/data behavior plus TLS | Login/TLS works but data port fails, or certificate issue blocks negotiation |
Swipe horizontally to see the firewall comparison.
FTP login succeeds but directory listing hangs
The control session on TCP 21 is established and authentication succeeds. Passive mode selects TCP 50042 for the data connection, but the firewall permits only TCP 21.
Diagnosis: data-channel policy, not control-port reachability. Smallest correction: permit the intended passive range according to server design. Verification: login, list, upload, and download through the real firewall path.
SFTP and SSH shell both fail to the same host
Neither SSH nor SFTP can establish a session on TCP 22. Because both depend on the SSH transport, investigate route, firewall policy, server SSH listener, and authentication before focusing on SFTP-specific directory permissions.
If the SSH shell begins working but SFTP still fails, the boundary shifts to SFTP subsystem/account restrictions.
SSH works but SFTP upload is denied
The client authenticates over SSH and can open a shell, but SFTP upload to `/incoming` returns permission denied. The network path and SSH transport are already proven to a useful degree.
Next evidence: SFTP subsystem configuration, account chroot, filesystem ownership/permissions, quota, or directory authorization.
FTPS reaches the server but reports a certificate-name mismatch
The TCP session reaches the server and TLS negotiation begins, but the certificate identity does not match the hostname the client used.
This is strong evidence that basic IP reachability exists. Investigate certificate name, trust, validity, and server configuration rather than changing the client subnet mask or default gateway.
Passive FTPS authenticates but transfers fail through NAT
The client completes TLS-protected authentication, the server advertises a passive port, but the advertised address/port cannot be reached from the client’s side of the NAT boundary.
The failure is not “TLS is broken.” Authentication and TLS succeeded. Inspect passive-port advertisement, NAT translation, firewall policy, and the server’s configured external address/range.
Read the architecture clues instead of relying on names
| Clue | Most consistent protocol |
|---|---|
| SSH service, one encrypted TCP 22 session | SFTP |
| TCP 21 control plus separate data connection, no transport encryption | FTP |
| FTP control/data behavior plus TLS/certificate negotiation | FTPS |
| Login works but passive listing fails on negotiated high port | FTP or FTPS data-channel issue |
| SSH shell and file transfer fail together | Shared SSH/SFTP transport issue |
Swipe horizontally to see the protocol-identification table.
Replacing FTP with SFTP is an application migration, not a firewall-port edit
An FTP-to-SFTP migration changes protocol architecture. Client software/configuration, automation scripts, server service, authentication, SSH host-key trust, firewall rules, account permissions, directory restrictions, logging, monitoring, and partner dependencies can all change.
Simply replacing TCP 21 with TCP 22 does not convert an FTP server into SFTP.
Inventory every dependency before retiring the old transfer service
- Which clients, scripts, vendors, and scheduled jobs still use FTP?
- Will the replacement be SFTP or FTPS?
- What authentication method will each client use?
- Which source networks should be allowed?
- Which directories and operations are required?
- Does SFTP require shell access, or should it be restricted?
- For FTPS, what certificate lifecycle and passive range are required?
- How will failures, logging, and rollback be handled?
Secure transport does not compensate for overprivileged accounts
An upload-only partner should not automatically receive shell access or broad filesystem visibility. A backup process may need write access to one directory but no interactive login. A read-only distribution account should not be able to overwrite files.
Common transfer results prove less than they appear to
| Evidence | Supports | Does not prove |
|---|---|---|
| FTP login succeeds | Control channel + auth succeeded | Data channel works |
| TCP 22 reachable | Transport reaches service port | SSH auth or SFTP subsystem works |
| SSH shell works | SSH transport/auth works | SFTP permissions/subsystem works |
| FTPS TLS handshake begins | Network path reaches TLS stage | Certificate is trusted or data channel works |
| Upload succeeds | One write path works | Read access, delete restrictions, or source restrictions are correct |
Swipe horizontally to see the evidence table.
Use the symptom to choose the protocol layer that actually failed
| Symptom | Inspect first |
|---|---|
| FTP cannot connect at all | Route, firewall, TCP 21 listener, authentication |
| FTP login works; listing fails | Active/passive mode, data port, NAT/firewall |
| SFTP + SSH both fail | TCP 22 path, SSH listener, auth |
| SSH works; SFTP upload denied | SFTP subsystem, filesystem permissions, chroot, quota |
| FTPS certificate warning | TLS certificate name/trust/validity |
| FTPS login works; transfer fails | FTP data-channel behavior through firewall/NAT |
Swipe horizontally to see the troubleshooting matrix.
FTP troubleshooting gets easier when you write down which connection has actually succeeded
Because FTP-family protocols separate command/control from data transfer, a single “connected” status is ambiguous. Authentication may succeed on the control channel while a directory listing, upload, or download fails on a different connection. The best troubleshooting answer names the exact channel and direction.
| Observed result | Known-good evidence | First unresolved dependency |
|---|---|---|
| TCP 21 connects, login prompt appears | Control path reaches FTP service | Authentication and later data path |
| Login succeeds, LIST hangs | Control + authentication succeeded | Negotiated data connection |
| Directory listing succeeds, upload denied | Control/data path works for listing | Write authorization, quota, filesystem permissions |
| Download succeeds, upload fails | Read operation/path works | Write permission or upload-specific policy |
Swipe horizontally to see the channel-evidence table.
A negotiated passive port is a concrete artifact you can trace through NAT and firewall policy
Hypothetical client transcript 220 File service ready USER student 331 Password required PASS ******** 230 Login successful PASV 227 Entering Passive Mode (...,195,122) Calculated server data port: 195 × 256 + 122 = 50042
The point is not to memorize this exact example. It is to recognize that FTP can negotiate a separate data destination. If the control channel works but TCP 50042 is blocked, the evidence isolates the failure much more precisely than saying “the FTP server is down.”
Application-aware inspection can help FTP, but you should not assume every firewall handles it the same way
Some stateful firewalls can inspect FTP control traffic and dynamically permit related data connections. Others require explicit passive ranges or additional configuration. Encryption can also change what an intermediary can inspect, which matters for FTPS deployments.
For AP Networking reasoning, avoid vendor-specific assumptions unless the prompt gives them. Base the answer on the documented server mode, negotiated ports, firewall policy, and observed flow.
A TLS certificate error is an identity/trust problem after basic connectivity has already progressed
If an FTPS client reaches the server and reports a certificate-name mismatch, expired certificate, or untrusted issuer, the session has advanced beyond basic routing and TCP reachability. That timing is valuable evidence.
| TLS symptom | Most relevant evidence | Weak response |
|---|---|---|
| Name mismatch | Hostname used vs. certificate identity | Change subnet mask |
| Expired certificate | Certificate validity period and client/server time | Open more passive ports |
| Untrusted issuer | Trust chain / CA configuration | Restart the router |
Swipe horizontally to see the TLS troubleshooting table.
SFTP security includes verifying the SSH server identity, not only encrypting the session
An SSH-based transfer can be encrypted while still connecting to the wrong server if host identity is not verified correctly. SSH host keys provide a mechanism for clients to recognize the intended server. Automation should handle expected host-key changes deliberately rather than disabling verification simply to make scripts run.
This creates a useful security boundary: encryption protects confidentiality/integrity in transit, while host-key verification helps establish that the client is talking to the expected SSH endpoint.
Automated transfers need tighter controls because credentials can run without a human watching
Scheduled file transfers often use service accounts, stored keys, fixed source systems, and predictable directories. That creates an opportunity for least privilege: restrict the source network, account, directory, command/subsystem capability, and operations to exactly what the automation needs.
A strong migration test should therefore include not only “did the nightly transfer run?” but also “can this service account do anything beyond the intended transfer?”
Positive: scheduled upload succeeds to the approved directory.
Negative: the same account cannot open an unnecessary shell, write outside the approved directory, or connect from an unauthorized source.
Active FTP can fail even when the client-to-server control path is perfect
In active mode, the server initiates the data connection back toward the client. If the client sits behind NAT, the address/port information advertised in the FTP exchange may not map cleanly to a reachable client socket. The return connection may be blocked by the client firewall or lost at NAT.
That is an important counterexample to one-way thinking: successful outbound TCP 21 does not prove the reverse data path can be established.
Choose the transfer protocol from the environment's constraints, not from a single “most secure” label
| Requirement | Protocol tendency | Reasoning |
|---|---|---|
| Existing SSH identity/key infrastructure | SFTP may fit naturally | Reuses SSH transport/auth model |
| Partner explicitly requires FTP semantics + TLS | FTPS | Preserves FTP behavior while adding TLS |
| Legacy unmanaged transfer with no encryption requirement | FTP may exist, but security risk must be acknowledged | Operational compatibility does not erase credential/data exposure |
| Simple firewall path desired | SFTP often simpler | No FTP-style negotiated data channel |
| Certificate-based server identity required | FTPS can align well | TLS certificate model |
Swipe horizontally to see the selection matrix.
The table shows tendencies, not universal answers. The prompt's actual interoperability and security requirements decide.
Eight FTP/SFTP/FTPS statements that are too broad
- “SFTP is FTP over SSH.” It is an SSH file-transfer protocol with different architecture.
- “FTPS is the same as SFTP.” FTPS is FTP protected by TLS.
- “Opening TCP 21 fixes FTP.” Data-channel ports may still be blocked.
- “Port 22 open means SFTP works.” Auth, subsystem, and permissions may still fail.
- “Encrypted transport means secure design.” Account scope and directory authorization still matter.
- “FTP login success proves file transfer works.” Control and data paths are separate.
- “A certificate warning is a routing problem.” It proves the connection reached TLS negotiation.
- “Migrating FTP to SFTP is changing the port.” It changes protocol, clients, authentication, scripts, and server behavior.
Build answers from protocol architecture and exact evidence
Protocol: FTP, SFTP, or FTPS?
Transport/control evidence: what port/session succeeds?
Mechanism: separate FTP data channel or single SSH session?
Security: plaintext, SSH, or TLS?
Boundary: what does the successful stage not prove?
Next artifact: passive range, SSH listener, certificate, permissions, logs.
Verification: perform the actual required transfer and a least-privilege negative test.
Verify both transfer functionality and the security requirement
For FTP-style services, test the actual active/passive mode through the real firewall/NAT path. For SFTP, verify SSH host identity, authentication, SFTP subsystem behavior, and directory permissions. For FTPS, verify certificate trust/identity and the required FTP data channels.
Then add a negative check: unauthorized source, bad credentials, or disallowed directory/action should fail.
24 FTP vs. SFTP vs. FTPS digital flashcards
Practice protocol identity, ports, control/data architecture, encryption, authentication, firewall behavior, NAT, certificate evidence, least privilege, migration, and verification.