How SFTP Works: The SSH Session, Keys, Port 22, and Commands, With a Diagram

SFTP is the SSH File Transfer Protocol, a subsystem of SSH, and everything about how it behaves follows from that one fact. There is no separate SFTP daemon listening on its own port, no second connection for data, and no encryption layer bolted on afterward. A client opens an SSH session on port 22, authenticates the way SSH authenticates, asks for the sftp subsystem, and from then on every directory listing, upload, download, rename, and permission change travels down the same encrypted channel. Despite the name, none of this is FTP: the two protocols share three letters and nothing else.

That design is why SFTP is the protocol most partner exchanges standardize on. One port to open on a firewall, one set of credentials or keys to manage, and one place where the transfer either succeeds or fails. This post walks the session from the TCP handshake to the last bye, with a diagram, then covers the two authentication methods, the commands as they appear on the wire, and the parts of the design that shape what a server can offer.

The protocol was specified as part of the SSH-2 suite in the early 2000s and went through several IETF drafts (draft-ietf-secsh-filexfer) without ever reaching full RFC status; version 3 of the draft, from 2002, is the form everything implements. Every Linux distribution ships an SFTP server inside OpenSSH, every Unix-like system ships a client, and every file-transfer tool in production supports it.

How SFTP works under the hood

SFTP runs entirely inside a regular SSH session. The mechanics:

1. Client opens an SSH connection to the server on port 22 (or whatever non-standard port the SSH daemon is configured for). The SSH handshake negotiates encryption ciphers, exchanges host keys, and verifies the server's identity.
2. Client authenticates — either with a username and password, or with an SSH key pair (a private key on the client, the corresponding public key listed in the server's ~/.ssh/authorized_keys).
3. Client requests the sftp subsystem via the SSH session. The server spawns an SFTP server process and begins speaking the SFTP wire protocol inside the existing encrypted SSH channel.
4. All file operations flow over that single channel — directory listing, upload, download, rename, delete, permission change, symlink creation, file resume.

That's the whole picture. One port, one connection, one encrypted stream. Everything SFTP gets — encryption, authentication, key management, host verification — it inherits from SSH.

A simplified diagram:

       ┌──────────────┐                      ┌──────────────┐
       │  SFTP        │   ── TCP/22 ──>      │  OpenSSH     │
       │  Client      │  SSH handshake       │  Daemon      │
       │              │  + auth + encrypted  │              │
       │ (FileZilla,  │  SFTP subsystem      │  ┌────────┐  │
       │  WinSCP,     │ ────────────────>    │  │  sftp- │  │
       │  Cyberduck,  │ <────────────────    │  │  server│  │
       │  CLI sftp)   │                      │  └────────┘  │
       └──────────────┘                      └──────────────┘

The single-channel design is the main reason SFTP is so much friendlier than FTP through firewalls and NATs. There's no separate data connection to negotiate; everything happens inside the SSH tunnel.

Authentication: passwords vs SSH keys

SFTP inherits SSH's two authentication models:

• Password authentication — client sends username and password inside the encrypted SSH channel. The server checks them against its local user database (or LDAP / PAM-backed alternatives). Simple, but rotating credentials means changing the password on every client that connects.
• Public-key authentication — the more common choice in production. The client generates a key pair (private key stays on the client; public key gets installed in the server's ~/.ssh/authorized_keys for that user). Every connection signs a challenge with the private key; the server verifies with the public key. No password transits the wire. Rotating a key means installing a new public key and removing the old one — a finite, scriptable operation.

For automated workflows — partner integrations, scheduled batch transfers, server-to-server replication — public-key authentication is the right answer. For interactive human use, either works, though key-based auth is also the better choice once a user has it set up.

What SFTP commands look like

The OpenSSH sftp command-line tool is the canonical SFTP client and ships on every Unix-like system. A session looks like this:

$ sftp alice@sftp.example.com
The authenticity of host 'sftp.example.com (203.0.113.5)' can't be established.
ED25519 key fingerprint is SHA256:abc123…
Are you sure you want to continue connecting? yes
alice@sftp.example.com's password: ********
Connected to sftp.example.com.
sftp> cd /reports
sftp> ls
report-2026-04.csv  report-2026-05.csv
sftp> get report-2026-05.csv
Fetching /reports/report-2026-05.csv to report-2026-05.csv
100%  142KB  142.0KB/s  00:00
sftp> put forecast.xlsx
Uploading forecast.xlsx to /reports/forecast.xlsx
100%   54KB   54.0KB/s  00:00
sftp> bye

The command set is familiar to anyone who's used FTP — cd, ls, get, put, mget, mput, rm, mkdir, pwd, bye. The differences are operational, not syntactic: every command rides inside the encrypted SSH session, and get / put resume support is native.

In practice, most non-CLI users connect through a graphical SFTP client — FileZilla, WinSCP, Cyberduck, Transmit — all of which support SFTP alongside FTP and FTPS. The protocol choice is usually a dropdown in the connection dialog; the rest of the workflow is the same drag-and-drop file management as any FTP client.

What businesses use SFTP for

SFTP is the modern default for secure file transfer. Where it shows up most often:

• B2B partner exchange. Trading partners drop signed files, EDI documents, or batch reports into directories on each other's SFTP endpoints. Healthcare claims, retail purchase orders, financial statements, ERP-to-ERP feeds — all standard SFTP shapes.
• Payroll and HRIS submissions. ADP, Paychex, Workday, and most HRIS vendors accept payroll batches over SFTP. The directory is usually customer-specific; the credentials are SSH keys provisioned during onboarding.
• Banking and treasury operations. Wire instructions, ACH batches, end-of-day reporting between banks and corporate treasury systems — almost universally SFTP.
• Healthcare record exchange. PHI moving between providers, payers, and clearinghouses. HIPAA doesn't prescribe a specific protocol, but SFTP's encryption-by-default makes it the easiest to defend in an audit.
• Backup and replication. Server-to-server file sync, log shipping, database dumps moved to off-site storage. rsync over SSH is a related cousin; pure SFTP works for the same job.
• CI/CD artifact distribution. Builds drop binaries on a release server; downstream systems pull via SFTP. Less common now that artifact registries (S3, GitHub Packages, etc.) have replaced it, but still seen in regulated build environments.

What SFTP is not the right tool for: anything that needs a REST API, multi-tenant sharing with external users, web-UI file browsing, programmatic access from JavaScript or other browser code. Those workflows want a managed platform or object storage with a real API.

Why teams stop running SFTP servers themselves

A self-hosted SFTP server (OpenSSH plus chroot, or a dedicated SFTP daemon like proftpd in SFTP mode) is one of the easier protocols to stand up. The harder part is what happens after.

• User and key management. Adding a partner means provisioning a Unix user (or a virtual user), installing their public key, restricting their shell to a chroot directory, and remembering to rotate. The per-partner overhead adds up.
• Audit logging. Every regulator wants "show me who downloaded which file when." OpenSSH's default logs don't do this cleanly; you end up patching together audit.d rules, auditd, or a dedicated audit-trail layer.
• Compliance scoping. SOC 2, HIPAA, PCI — every audit asks who can access what, with what controls, with what evidence. Owning the SFTP server means owning the answers.
• Cipher hygiene. OpenSSH cipher recommendations evolve every couple of years. Keeping your sshd_config current is your scope.
• Multi-protocol pressure. Partners want SFTP today, FTPS next quarter, AS2 the year after. Running each protocol on its own self-hosted stack triples the operational surface.

For teams that want the protocol without owning all of that, a managed platform is the right shape.

The modern way to run SFTP

Files.com is the File Orchestration Platform we'd recommend for any team running SFTP workflows in 2026. The platform exposes SFTP on port 22 on a subdomain Files.com provisions, and handles the operational surface that makes self-hosting painful:

• SFTP on port 22 with native SSH key auth. Per-user keys, rotation, revocation through the admin UI or the REST API.
• FTP, FTPS, and WebDAV on the same backend storage. Same files, same users, all four protocols available — partners pick whichever client they already have.
• Per-file, per-user audit logging. Immutable trail, exportable on demand. Drops straight into a SOC 2 evidence collection.
• SOC 2 Type II and HIPAA-BAA out of the box. The compliance posture is Files.com's responsibility, not yours.
• Modern features SFTP alone never had. REST API + SDKs in 8 languages, automation workflows triggered on file arrival, AS2 partner messaging, share links with passwords and expiry, a browser-based file manager.
• MFA, IP allowlisting, SSO with SAML/SCIM, integrations with the rest of your stack. Enterprise security posture without a dedicated SFTP engineer.

Start a free Files.com trial — no credit card, provisioned in about 10 minutes. Generate keys in the UI, hand them to your partners, and the SFTP endpoint is live.

For the narrow set of teams that must run file-transfer infrastructure inside their own datacenter — air-gapped environments, strict data-residency mandates, regulated workloads that prohibit multi-tenant cloud — the free ExaVault on-premise appliance handles SFTP / FTP / FTPS / WebDAV from a self-hosted VM image.

FAQ

What does SFTP stand for?

SFTP stands for SSH File Transfer Protocol. The "S" refers to SSH (Secure Shell), the underlying protocol that provides the encrypted transport. SFTP is a file-transfer subsystem of SSH, not a variant of FTP.

What port does SFTP use?

Port 22, the same as SSH. If the SSH daemon runs on a non-standard port (port 2222 is a common choice), SFTP follows whatever port SSH is on.

Is SFTP the same as FTPS?

No. SFTP is a subsystem of SSH that runs on port 22 with native encryption. FTPS is the original FTP protocol with a TLS encryption layer added; it runs on port 21 (with TLS upgrade) or port 990 (implicit TLS) and inherits all of FTP's dual-channel firewall complexity. See the full comparison.

Is SFTP the same as FTP over SSH?

Almost — "FTP over SSH" usually means tunneling the original FTP protocol through an SSH connection (port-forwarding the FTP control + data channels), which is awkward and rarely deployed. SFTP is not FTP over SSH in the strict sense; it's a separate file-transfer protocol that happens to run inside an SSH session. The distinction matters because SFTP doesn't carry FTP's dual-channel quirks.

What's an SFTP server?

An SFTP server is the server-side software that accepts incoming SFTP connections. On Linux and macOS, this is built into OpenSSH (the sftp-server subsystem). Standalone implementations include ProFTPD with mod_sftp, VShell, and the SFTP modes of commercial MFT platforms.

What's an SFTP client?

An SFTP client is the software you use to connect to an SFTP server. Common options: OpenSSH sftp (CLI, ships on every Unix-like system), FileZilla, WinSCP (Windows), Cyberduck (cross-platform), Transmit (Mac). All major automation libraries — Paramiko (Python), JSch (Java), ssh2 (Node.js), golang.org/x/crypto/ssh — also speak SFTP.

How do I generate SSH keys for SFTP?

On a Mac or Linux shell:

ssh-keygen -t ed25519 -C "your_email@example.com"

This creates ~/.ssh/id_ed25519 (private key, stays on your machine) and ~/.ssh/id_ed25519.pub (public key, install in the server's authorized_keys). The ed25519 key type is the modern default; older rsa keys (with a 4096-bit length) are also fine. See our SSH-keys-for-passwordless-login guide for the full walkthrough.

Is SFTP secure?

Yes — SFTP encrypts every byte (credentials, commands, file contents) with the underlying SSH session's cipher suite. The current OpenSSH defaults use modern AEAD ciphers (ChaCha20-Poly1305, AES-256-GCM) and Curve25519 key exchange, both of which are considered strong against any realistic adversary in 2026.

Can I use SFTP in a web browser?

Not directly — browsers don't speak SFTP. The modern alternative is a hosted platform like Files.com that exposes both an SFTP endpoint and a browser-based file manager pointing at the same backend storage; users get a web UI for interactive work, automation gets SFTP for scripted transfers.