Secure file transfers

FTPS and SFTP both hide the password. They are still different protocols, and each one has its own identity check. That check is part of the connection, not an extra click.

What plain FTP exposes

FTP sends the username, the password, and the file bytes without encryption. Anyone who can watch the path between you and the server can read them. That includes an open wireless network and a compromised device on a network you thought was private. FileZilla labels the plain setting as insecure for that reason. Use it only when no encrypted option exists and you accept the exposure. It is not a fallback when FTPS or SFTP is difficult.

FTPS is not SFTP

FTPS is FTP inside TLS. It still has a control connection and a data connection, still uses FTP reply codes, and still needs a passive port range. SFTP is a file-transfer subsystem of SSH. One encrypted session carries the login and the files. It does not send PASV, it does not use a TLS certificate, and the FTP encryption menu in Site Manager does not apply to it.

Tunneling the old FTP port through an SSH local forward is a third, less common arrangement. It is not what FileZilla means by the SFTP protocol. If an operator says “SFTP,” build the SFTP profile in the setup guide. If they say “FTP with TLS,” “FTPS,” or “explicit SSL,” build the explicit FTPS profile.

Identity check
FTPS shows a TLS certificate. SFTP shows an SSH host key. Compare the fingerprint either way.
Usual port
Explicit FTPS on 21. Implicit FTPS on 990. SFTP on 22.
After a bad password
FTPS returns an FTP 530. SFTP returns an SSH authentication error. Neither error means you should disable encryption.

Explicit TLS and implicit TLS

Explicit FTPS connects to the FTP port, sends AUTH TLS, and upgrades. You should see 234 before the username is sent. Require this mode in Site Manager so FileZilla will not continue in the clear if the server declines TLS.

Implicit FTPS wraps the socket in TLS from the first byte. There is no plain 220 before the handshake. It belongs on the port the operator reserved for it, commonly 990. Selecting it on port 21 produces a TLS-packet error because the server is still speaking FTP. That error is a mode mismatch, not a reason to trust a random certificate.

How to read the certificate dialog

FileZilla shows the certificate when it cannot already tie the server to a certificate you trust. Look at three things:

  • The hostname. It should match the host you typed, either as the common name or as a subject alternative name. Connecting by raw IP fails this check when the certificate names a hostname. Use the name, or a certificate that lists the IP, instead of overriding the warning.
  • The dates. A clock set months off on your computer makes a valid certificate look expired. Correct the clock before you accept anything unusual.
  • The fingerprint. Compare it with a fingerprint the operator gave you on a channel other than the FTP session itself. A phone call, a panel page you already trust, or a signed message all qualify. The certificate dialog alone does not.

Trust the certificate for that site only after those three agree. A changed fingerprint on a server you have used before is a reason to stop and ask what changed. It can be a planned certificate replacement. It can also be something on the path presenting its own certificate.

GnuTLS errors such as “An unexpected TLS packet was received” usually mean this port is not speaking the TLS mode you selected. Sort that with connection errors before you consider the certificate untrustworthy.

How to read the SSH host key

The first SFTP connection has the same job as the certificate dialog. FileZilla shows the key type and a fingerprint. Trust it only when it matches the operator’s published fingerprint. On later connections, FileZilla remembers the key. If the server presents a different key, treat the session as untrusted until the operator explains the change. Reinstalling SSH can change a host key. So can a machine that is not the server you wanted.

“Algorithm negotiation failed” means the client and the server could not agree on SSH algorithms. That is a server-configuration problem for the operator. It is not solved by using plain FTP, and it is not solved by deleting the known host key and clicking through.

Keys you use to log in

An SSH login key is separate from the server’s host key. You hold the private login key. The server holds your public login key. FileZilla needs the private file in the Key file field or in Edit → Settings → Connection → SFTP. Protect that file the way you protect a password. A passphrase on the key means a copy of the file is not enough to log in, but a copy is still something you should stop using if it leaves your computer. The authentication guide covers the matching public key and the “publickey” rejection.

What has to be true on the server

These are checks for the person who runs the server, not switches in FileZilla:

  • The FTPS certificate name matches the hostname users type, and the date range covers today.
  • The passive address is the public address clients use, and the passive port range is forwarded one-to-one to the FTP service.
  • The data connection is allowed to resume the same TLS session. Clients should not be told to weaken that check.
  • The SSH host key is stable, and its fingerprint is published where users can read it without already trusting the SSH session.
  • Plain FTP is not the internet-facing option when FTPS or SFTP can be offered.

A listing that fails with a TLS session that was not resumed is diagnosed in directory listing problems. The client-side repair is not “turn TLS off.”

Checks that should stay enabled

Do not make any of these the normal fix: selecting “Only use plain FTP,” accepting a hostname mismatch, trusting a certificate you did not compare, or deleting a changed SSH host key so the prompt goes away. Each one connects you to whatever answered. That is a weaker position than the error you were trying to clear.

If a security product on your computer intercepts TLS, it can cause both a strange certificate and a failed data-connection resume. The consistent fingerprint check is how you notice it. The product’s own documentation is the place to exclude a trusted server, if you decide to. Filenilla cannot see that product and will not ask you to disable certificate validation globally.

How to tell the session is actually protected

Explicit FTPS is protected when AUTH TLS received 234, the certificate matched the hostname and the published fingerprint, and the login happened after that handshake. SFTP is protected when the host-key fingerprint matched and authentication used the SSH session. A green status bar without those lines is not the same evidence. Keep the message log visible the first time you connect to a new host, and again whenever the fingerprint prompt returns.