SFTP commands: how SFTP differs from FTP — and what you'll actually use

If you've used FTP, the SFTP client commands will feel almost identical: ls, cd, get, put, rm, mkdir. What's happening underneath, though, is completely different. Understanding the difference matters because it explains why SFTP is secure by default, why it doesn't have the firewall headaches FTP has, and why you can use SSH keys, MFA, and a single port for everything.

SFTP is not "FTP over SSH"

The name is misleading. SFTP — the SSH File Transfer Protocol, defined in draft-ietf-secsh-filexfer-02 — is not FTP wrapped in encryption. It's a separate protocol that runs as a subsystem of SSH. Different commands, different wire format, different security model.

Side-by-side comparison:

The single-port property is the practical one. With FTP, the data connection uses a fresh port per transfer, which means firewalls need to do FTP protocol inspection to know which ports to let through. With SFTP, all bytes — control, file content, status — flow on the same encrypted SSH connection on port 22. Nothing else to configure.

How to connect

The simplest way to start an SFTP session is from a terminal:

$ sftp alice@example.com
alice@example.com's password:
Connected to example.com.
sftp>

You can also connect using a public key instead of a password — the recommended approach for any account you'll use more than once:

$ ssh-keygen -t ed25519           # generates ~/.ssh/id_ed25519 and id_ed25519.pub
$ ssh-copy-id alice@example.com   # adds your public key to the server's authorized_keys
$ sftp alice@example.com           # no password prompt this time

Once connected, the prompt becomes sftp> and you can type commands interactively.

Moving around

SFTP keeps a current directory on both ends of the connection. The l-prefixed commands act on the local side.

Listing files

Transferring files

The most common SFTP commands. Everything is one-shot — no separate "open data connection" step.

Behind the scenes each get turns into a sequence of SFTP packets: SSH_FXP_OPEN to open the file, repeated SSH_FXP_READ requests to pull bytes, and a final SSH_FXP_CLOSE. You won't see these in the prompt, but they're worth knowing if you ever read the protocol spec or have to debug an interop issue.

Creating, deleting, renaming

Permissions and ownership

FTP doesn't have a standard way to change file permissions — you have to use SITE CHMOD, which is vendor-specific. SFTP, because it's modelled on POSIX file attributes, has these built in:

Help and exit

What to do next

If you're coming from FTP, the muscle memory transfers directly: get, put, ls, cd all do what you expect. The wins are everything you don't have to think about — one port, encrypted, key-based auth, no separate data connection — and they're all happening because SFTP rides on SSH instead of being a layer over FTP.

A few practical next steps:

• Generate an SSH key with ssh-keygen -t ed25519 if you haven't already. It's the modern default and replaces password auth for everything you'll ever automate.
• Read ~/.ssh/config documentation. It lets you give each host a short alias and store its hostname, port, username, and key path so you can just type sftp prod instead of sftp -P 2222 -i ~/.ssh/prod_key alice@prod.example.com.
• If you're running a server, configure it to require public-key authentication on automation accounts and to require MFA on human accounts. The same SFTP listener can do both, per account.
• For the gory details of the protocol — packet types, status codes, attribute bitmasks — read the draft specification. It's surprisingly readable.