SFTP

In the IETF drafts (draft-ietf-secsh-filexfer), the client talks to a subsystem named "sftp" inside an SSH connection. It is not FTP, and it is not FTP with TLS.

The naming fight is the whole entry. "Secure File Transfer Protocol" is a back-formed expansion. The draft title is SSH File Transfer Protocol. FTPS is the other secure-FTP phrase, and it means FTP plus TLS as in RFC 4217. A partner who says "send it SFTP" and then offers port 21 is describing FTPS or plain FTP. SFTP almost always listens on the SSH port, 22, and does not open a second data port. One TCP connection carries login and bytes. That is why it survives firewalls that break FTP's data channel.

The protocol was never published as an RFC. The secsh working group left it as an Internet-Draft; version 3 is what most servers still speak, and later drafts added versions the installed base only partly follows. OpenSSH implements the widely deployed behavior, which does not match every line of the last draft. Interoperability arguments in production are usually version and extension arguments, not "is SSH up."

A payroll vendor requires SFTP to `sftp.vendor.example` on port 22, with a public key, a chroot, and a drop folder `/inbound`. The job connects, authenticates with the key, and writes `earnings-2026-10-06.csv`. The server never sees a cleartext password on the wire because SSH already encrypted the session. If someone configured the same host for FTP on port 21 and reused the word SFTP in the runbook, the key will not work and the file will not land.

SFTP can list, rename, and remove files, so it is a remote file protocol, not only a copy pipe. SCP is the older SSH copy command. It moves a file. It does not offer the same directory operations, and many "scp" binaries now speak SFTP underneath. Encryption here is encryption in transit provided by SSH. It does not encrypt the file on disk after the session ends. That is a separate control.