SFTP File Transfer: Connect, Transfer, and Verify

This post is the practical zero-to-working-SFTP walkthrough — pick a client, configure the connection, transfer a test file, verify it landed. The target use case: a partner just sent you SFTP credentials (or your IT team handed you a hostname and username) and you need to be moving files in the next ten minutes. For the protocol-level explainer of how SFTP works, see our canonical "What is SFTP?" post.

What you'll need

• An SFTP client — FileZilla (free, cross-platform), WinSCP (free, Windows), Cyberduck (free, Mac), Transmit (paid, Mac), or the OS-bundled sftp CLI on any Unix-like system.
• Connection details: hostname (something like sftp.example.com), username, port (almost always 22), and either a password or an SSH key.
• A test file to transfer first, before you trust the connection with anything important.

If you don't have an SFTP server to test against, start a free Files.com trial — provisions an SFTP endpoint with credentials in about 10 minutes.

Step 1: Pick a client

For a one-off transfer, FileZilla is the friction-free pick — free, runs on every OS, you can be connected in 60 seconds. For ongoing daily use, the per-OS premium options (Transmit on Mac, WinSCP on Windows) are nicer.

For scripted or scheduled transfers, the CLI (sftp on Linux/macOS, available on modern Windows via OpenSSH) or a language library (paramiko for Python, ssh2 for Node, lftp for shell scripts) is the right shape.

See our 7 FileZilla alternatives roundup for the longer comparison if you're picking for the long term.

Step 2: Configure the connection

In FileZilla (the most common starting point):

1. Open File → Site Manager (or Ctrl+S / ⌘S).
2. Click New site and give it a name (e.g., "Acme Partner SFTP").
3. Fill in:
   • Protocol: SFTP — SSH File Transfer Protocol
   • Host: the hostname your partner gave you (sftp.example.com)
   • Port: 22 (leave blank if 22; the default)
   • Logon Type: Normal (for password) or Key file (for SSH key)
   • User: your username
   • Password / Key file: your password or the path to your private key
4. Click Connect.

For the CLI:

sftp alice@sftp.example.com

Add -i ~/.ssh/your-key if you're using a non-default key file. Add -P 2222 if the server uses a non-standard port (note: capital P for sftp, lowercase p for ssh).

Step 3: Verify the host key

The first time you connect to a new SFTP server, the client will prompt to verify the server's host key fingerprint. This is SSH's host-key verification — confirms you're talking to the real server rather than a man-in-the-middle.

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?

The right way: your partner or server admin should have given you the expected fingerprint out of band (a separate channel — email or phone, not the same channel as the credentials). Compare what's shown to what they sent. If they match, accept; the fingerprint gets cached and verified on every subsequent connection. If they don't match, do not accept — something's wrong (a real MITM, or the server's been reinstalled).

The pragmatic reality: most one-off users don't have an out-of-band fingerprint to verify. In that case, trust on first use — accept the fingerprint, knowing that subsequent connections will detect any change (the client will refuse to connect if the host key changes, alerting you).

After accepting, the host key is cached in ~/.ssh/known_hosts (CLI) or the client's known-hosts store (FileZilla et al.).

Step 4: Transfer a test file

Before transferring anything important, prove the connection works with a small test file.

In a graphical client:

• Local pane (your machine) on the left, remote pane (the SFTP server) on the right.
• Navigate to a working directory on each side.
• Drag a small test file (10 KB or so) from local to remote.
• Watch the transfer queue. Status should go from "Queued" to "Transferring" to "Completed."

In the CLI:

sftp> put test.txt
Uploading test.txt to /home/alice/test.txt
100%  148B  148.0B/s  00:00
sftp> ls
test.txt

If the upload completes and the file shows in the remote listing, the connection works. Delete the test file (rm test.txt in CLI; right-click → Delete in graphical) once verified.

Step 5: Verify the transfer actually worked

Three quick checks that catch the most common transfer issues:

• File size matches. The size shown on the remote side should equal the size of the local file. If it's smaller, the transfer was interrupted (and silently — some clients don't always flag this).
• Checksum matches (for important files). On the client: sha256sum file.dat. On the server (if you have shell access): sha256sum file.dat. Both should produce the same hash.
• The file opens correctly. Open it on the destination side and verify the contents look right. Especially relevant for text files (line-ending corruption can sneak through if a client misconfigures binary mode).

For automated SFTP workflows, build size and checksum verification into the script — a "transfer completed" message from the FTP client isn't a guarantee of byte-perfect delivery.

Common gotchas

"Connection refused." Wrong port, or the server isn't listening on the expected port, or a firewall blocks outbound port 22 from your network. Test the port directly: nc -vz sftp.example.com 22. If nc reports "succeeded," the port is open; the issue is elsewhere (probably auth).

"Authentication failed." Username or password is wrong. For SSH key auth: the public key on the server doesn't match the private key on your client. Check with ssh-keygen -l -f ~/.ssh/id_ed25519.pub and compare to what the server's admin UI shows.

"Permission denied (publickey)." Same as authentication failure, but the server is explicitly configured for key-only auth (password disabled). Make sure you're using -i /path/to/key or that the right key is in ~/.ssh/. See our SSH keys guide.

"Host key verification failed." The server's host key has changed since you last connected. Either the server was reinstalled (re-trust by removing the old entry with ssh-keygen -R sftp.example.com) or — much less commonly — something on the network is intercepting the connection.

"Connection times out." Slow or unreachable server. See our diagnosing FTP speed problems guide for the debugging order.

Transfer succeeds but partner can't read the file. Filename encoding or line-ending issues. Modern SFTP is binary-safe and UTF-8 by default; if the partner is on a legacy system with Latin-1 filenames or expects \r\n line endings, you may need to adjust.

SFTP-to-SFTP transfer (server-to-server)

A common pattern: pull a file from one SFTP server, push to another. Either chain two sftp sessions on a local machine (download, then upload), or use rsync over SSH for direct server-to-server:

# From your workstation, transferring between two remote servers
rsync -av --progress \
  source-user@source-host:/path/to/file \
  dest-user@dest-host:/path/to/destination/

For ongoing server-to-server sync, a managed-file-transfer platform with built-in routing (Files.com has this) is cleaner than maintaining scripts.

The modern way

Files.com is the File Orchestration Platform we'd recommend for SFTP workflows in 2026. It provisions an SFTP endpoint on a subdomain in 10 minutes with native SSH key support, per-user credentials, audit logging on every transfer, and the operational surface (TLS, MFA, SSO, compliance) fully managed:

• SFTP, FTPS, FTP, WebDAV, AS2 all on the same backend storage.
• REST API + SDKs in 8 languages for automation that wants to skip the SFTP client entirely.
• Audit logging with per-file, per-user granularity.
• SOC 2 Type II, HIPAA-BAA, GDPR-ready posture.

Start a free Files.com trial — no credit card.

For teams that need to run file-transfer infrastructure inside their own datacenter, the free ExaVault on-premise appliance ships SFTP from a self-hosted VM image.

FAQ

What's the easiest SFTP client to start with?

FileZilla for graphical use (free, cross-platform, large community). OpenSSH sftp CLI for terminal use (built into every Unix-like system). For Mac users who'll be using SFTP daily, Transmit ($45) is worth the upgrade.

What port does SFTP use?

Port 22, the same as SSH. If the server uses a non-standard port (some shops put SSH on 2222 to reduce automated scanning noise), the SFTP client follows whatever port SSH is on — specify it explicitly.

How do I transfer files between two SFTP servers?

Three options. Locally chained: download from server A, upload to server B in two steps. rsync over SSH: direct server-to-server sync from your workstation (or a coordinating server with credentials for both). Managed-platform routing: a platform like Files.com can pull from one server and push to another via configured automation.

How do I verify an SFTP host key fingerprint?

Get the fingerprint from your partner / server admin out of band (separate channel from the credentials), then compare to what the SFTP client shows on first connection. The fingerprint is a hash like SHA256:abc123.... Match means trust; mismatch means don't.

Can I transfer multiple files at once over SFTP?

Yes. In the CLI: mput *.csv (multiple put with a glob). In graphical clients: select multiple files and drag-and-drop. For very large batches, the transfer queue lets you reorder and pause-resume individual files.

What happens if my SFTP transfer is interrupted?

Most modern clients support resume — the next transfer of the same file picks up where the interruption stopped. CLI: reput filename (upload resume) or reget filename (download resume). See our FTP resume guide.

How fast should SFTP transfers be?

Bounded by the slowest link in the network path between client and server. For most commercial internet connections, 10–50 MB/s is normal for same-region transfers; cross-region or congested paths can be slower. See our diagnosing FTP speed problems guide if your transfers are unusually slow.

Is SFTP the same as FTP over SSH?

Almost. "FTP over SSH" sometimes refers to tunneling the original FTP protocol through an SSH connection (awkward, rarely deployed). SFTP itself is a separate protocol — a file-transfer subsystem of SSH, not a tunneled FTP. The result feels similar from the client; the wire format underneath is different.