Cloud Parts

SFTP

The SSH File Transfer Protocol: binary file-system requests (open, read, write, list, rename) carried inside an encrypted SSH session on port 22. Not FTP, and never finished as an RFC.

What it is
Network protocols (file transfer protocols)
Type
Open source
Made by
IETF (secsh working group drafts)
License
Open specification (expired IETF Internet-Draft, never an RFC)
Facts checked
8 October 2026
Website

What it is

SFTP runs as the sftp subsystem of an SSH connection. SSH has already authenticated the server by its host key, logged the user in with a password or key, and encrypted the channel; SFTP only adds the file operations. The client sends SSH_FXP_INIT with its protocol version and the server answers with the lower of the two versions. From then on every request carries an ID and gets a reply: open a file and get a handle, read or write a range of bytes at an offset, close, list a directory, stat, rename, remove, make or remove directories, follow and create symlinks. A client may keep many requests outstanding at once, limited only by buffering and the SSH channel’s flow control. Commands and data share the one SSH connection, so there is no second port to open.

The name misleads: SFTP has nothing to do with FTP or FTPS, and TCP port 115, registered as “sftp”, belongs to an unrelated Simple File Transfer Protocol. The specification was never finished. The IETF’s Secure Shell working group revised the draft from protocol version 3 (draft-02, October 2001) up to version 6 (draft-13, July 2006), when it expired. OpenSSH’s sftp and sftp-server implement version 3 and say they won’t support newer drafts, adding features as named extensions instead, such as posix-rename@openssh.com. Version 3 is therefore what most servers speak, including managed services such as AWS Transfer Family, and since OpenSSH 9.0 (April 2022) the scp command uses SFTP underneath by default.

Why teams pick it

  • One TCP connection on one port (22) for commands and data: easy to firewall and to pass through NAT
  • Reuses SSH’s encryption, host keys and login methods, including key-based login for unattended jobs
  • A real remote file-system protocol: random-access reads and writes, attributes, renames and directory operations, not just whole-file copies
  • Many requests in flight on one connection, with flow control from the SSH channel

Watch out for

  • No RFC: implementations follow an expired draft, almost always version 3, and add their own extensions for missing features
  • Quirks are frozen in for compatibility: OpenSSH reverses the arguments of SSH_FXP_SYMLINK, and its standard rename differs from POSIX rename
  • Not compatible with FTP clients, servers or FTPS despite the name, so partners must agree which one they mean
  • Trust rests on SSH host keys: the client must already know the server’s public key, usually from a local list it maintains, and skipping that check on a first connection leaves it open to man-in-the-middle attacks

Alternatives

What all file transfer protocols have in common →
FTPOpen sourceThe File Transfer Protocol: text commands on a control connection to port 21, and a second TCP connection for every listing or file. Everything, passwords included, travels unencrypted.+1 FTPS

How it fits with other technologies

Fetch a file over SFTP from a public test server · bash

# record the server’s SSH host key first (verify its fingerprint out of band in real use)
ssh-keyscan -t ed25519 test.rebex.net >> ~/.ssh/known_hosts

curl -s -u demo:password sftp://test.rebex.net/readme.txt | head -1
# Welcome to test.rebex.net!

# OpenSSH’s client does the same interactively:
#   sftp demo@test.rebex.net   then   get readme.txt

See it in a real stack

No architecture uses SFTP yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1995–2022

Tatu Ylönen wrote the first version of SSH in spring 1995, at a time when telnet and FTP were widely used, and designed it to replace both. He asked IANA for a port in July 1995 and got 22, between FTP’s 21 and telnet’s 23. When SSH became popular he took it to the IETF, whose Secure Shell working group standardised SSH version 2 as RFCs 4251 to 4254 in January 2006.

File transfer was meant to be part of that suite. In October 2001 Ylönen and Sami Lehtinen of SSH Communications Security published the SSH File Transfer Protocol draft, version 3, describing it as the standard file transfer protocol for SSH2 and usable over any reliable data stream. The working group kept extending it, to version 6 in draft-13 of July 2006, but the draft expired and never became an RFC. OpenSSH had already shipped version 3 and decided not to follow the newer drafts. In April 2022 OpenSSH 9.0 switched scp from the old scp/rcp protocol to SFTP by default, because legacy scp expanded remote file names through the remote shell.

Why it’s built this way

A subsystem of SSH, not a protocol of its own on the wire
The draft assumes it runs over a secure channel where the server has already authenticated the user, so it needs no encryption or login of its own and inherits everything SSH provides.
File-system operations, not commands and files
The draft was designed so it could implement a secure remote file system as well as file transfer: handles, offsets and attributes rather than FTP’s whole-file RETR and STOR.
Negotiated versions plus vendor extensions
Both sides agree on the lower version at start-up, and SSH_FXP_EXTENDED lets implementations add named features without a new version, which is how OpenSSH grew it while staying on version 3.

Timeline

  1. 1995

    Tatu Ylönen releases SSH 1.0; IANA assigns it port 22

  2. 2001

    SSH File Transfer Protocol draft-02 defines protocol version 3

  3. 2006

    SSH-2 published as RFCs 4251 to 4254; SFTP draft-13 (version 6) is the last before it expires

  4. 2022

    OpenSSH 9.0 makes scp use the SFTP protocol by default

Sources9 · facts checked 8 October 2026

Improve this page on GitHub