Guide

SSH keys vs password authentication for SFTP

For SFTP, SSH keys are stronger and better suited to automation than passwords. Here's how each works, the trade-offs, and practical advice on managing keys for partners and machines.

SFTP runs over SSH, so you can authenticate users two ways: a password, or an SSH key pair. Both are encrypted in transit (that’s SSH’s job), so this isn’t about eavesdropping. It’s about how guessable, how phishable, and how automatable each one is. For most SFTP use, keys win.

How each works

  • Password: the user proves who they are with a shared secret. Simple, but it can be guessed, brute-forced, reused across services, or phished.
  • SSH key pair: the user holds a private key; you register their public key. They prove possession of the private key cryptographically. Nothing guessable is sent, and there’s no shared secret to leak.

Why keys are stronger

  • No brute-forcing. A 256-bit Ed25519 key is not something an attacker guesses. Passwords are.
  • No reuse risk. People reuse passwords across systems; a key is specific to this purpose.
  • Phishing-resistant. There’s no secret to type into a fake prompt.
  • Built for automation. A scheduled job or CI pipeline can use a key non-interactively without a password sitting in a script. See automate SFTP uploads with cron and SFTP in GitHub Actions.

When a password is acceptable

  • A human, occasional, low-risk transfer where issuing a key is more friction than it’s worth, and the password is strong and unique.
  • A partner who genuinely can’t manage keys. It happens. If you must use a password, make it long and random, and lean harder on the other controls below.

Even then, prefer keys where you can.

Practical key management

  • One key per partner or machine. Never share a key across clients, so you can revoke one without breaking the others.
  • Prefer Ed25519 (or RSA 3072+). Generate with ssh-keygen -t ed25519.
  • Protect private keys. They live on the client side; a passphrase on the private key adds a second factor for human users.
  • Rotate and revoke. When an engagement ends or a key may be exposed, remove the public key immediately. Instant revoke matters here.
  • Don’t email private keys around. The partner generates the pair and sends you only the public half.

In a managed gateway

A gateway like Firepipe lets you issue either per-user SSH keys or passwords, each path-jailed to its own prefix, and revoke any of them instantly (which also tears down live sessions). For anything automated, use keys. Combine that with a path jail and an audit trail, and you have defence in depth rather than a single guessable secret. See SFTP security best practices for the full checklist.

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

← All guides