Guide
SFTP security best practices: a practical checklist
A concrete checklist for running SFTP safely, per-user credentials, key auth, path jails, least-privilege storage access, audit logging, host-key verification, and revocation.
SFTP is secure by design (it runs over SSH), but a secure protocol doesn’t make a secure setup. Most SFTP incidents come from how it’s operated: shared logins, over-broad access, no audit trail, no revocation plan. Here’s a practical checklist that applies whether you run your own server or use a managed gateway.
1. One credential per partner or system
Never share a single login across clients. Issue one credential per partner or machine, so you can revoke one without breaking the rest, and so your audit trail actually tells you who did something.
2. Prefer SSH keys over passwords
Keys aren’t guessable or phishable and are built for automation. Reserve passwords for the rare case a partner can’t manage keys, and make them long and random. See SSH keys vs password authentication.
3. Path-jail every user
Scope each user to their own directory (prefix) so they can’t list or read anyone else’s files. This is the single most important containment control. See chroot directories explained.
4. Use least-privilege storage access
The server or gateway should only be able to touch what it needs. For S3, a scoped cross-account IAM role limited to one bucket and prefix; for Azure, GCS, and S3-compatible stores, a scoped access key you can rotate or revoke. Never wire in account-wide or root credentials.
5. Keep an audit trail
Record every connection and transfer: who connected, from where, what they uploaded, downloaded, or deleted, and when. You will eventually need to answer “did file X arrive?” or investigate an incident. See SFTP audit logging.
6. Verify host keys
Give partners your server’s SSH host-key fingerprint and have them pin it. Without
host-key verification, a client can be silently redirected to an impostor server. Don’t
encourage StrictHostKeyChecking=no.
7. Have a revocation plan
When an engagement ends or a key may be exposed, you need to cut access in seconds, and ideally tear down any live session too, not wait for a config reload. Test that you can.
8. Restrict where you can
Where a partner connects from a known network, pin their credential to specific source IPs so a leaked key is useless from anywhere else. (Note this is harder for cloud CI runners, which use wide, changing IP ranges, rely on key auth and path jails there instead.)
9. Encrypt at rest
Your transfer is encrypted in transit by SSH; make sure the destination is encrypted at rest too. Enable bucket-level server-side encryption (for example SSE-S3 on Amazon S3).
10. Disable plain FTP entirely
If anything in your stack still offers unencrypted FTP, turn it off. It sends credentials in cleartext. See why plain FTP is insecure.
How a gateway helps
A managed bring-your-own-bucket gateway gives you most of this by construction: per-user keys or passwords, mandatory path jails, least-privilege scoped access, an exportable audit trail, instant revoke with live-session teardown, and per-credential source-IP pinning, in front of a bucket you own. See SFTP to S3 and the Firepipe security model.
Try it on your own bucket
Connect a bucket you already own, Amazon S3, Azure Blob, Google Cloud Storage, or an S3-compatible store, and hand out a clean SFTP endpoint in minutes. Your files stay in your cloud.
Start free