How to Set Up SSH Keys for Passwordless SFTP Login

SSH keys solve two problems passwords don't: they're stronger against guessing (no human is ever going to crack a 256-bit Ed25519 key), and they support passwordless authentication — connect to a server without typing a password every time, which is what makes automated SFTP workflows actually work without storing passwords in plaintext config files. This post is the setup guide: generate a key pair, install the public key on the SFTP server, point your client at the private key, and you're done.

What an SSH key is

An SSH key is a key pair — two mathematically linked files:

• The private key stays on your machine, in ~/.ssh/. It's the secret half; treat it like a password. Anyone with your private key can authenticate as you.
• The public key gets installed on the server, in the user's ~/.ssh/authorized_keys. It's the half you share; possession alone proves nothing.

When you connect to the server, your SSH client signs a random challenge with the private key. The server uses the public key to verify the signature. If it matches, the server knows you have the private key without ever seeing it. That's the asymmetric-cryptography magic — proof of possession without disclosure.

The result: no password transits the network. The server's authorized_keys file is enough for you to log in; nothing on disk anywhere is sensitive enough to leak a working credential by itself (the public key is fine to share publicly; the private key stays on your machine).

Step 1: Generate a key pair

On macOS, Linux, or Windows (with Git Bash, WSL, or PowerShell with OpenSSH):

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

The flags:

• -t ed25519 chooses the Ed25519 key type — modern, fast, small (256-bit private key), and supported by every modern SSH server. The current best-practice default.
• -C "your_email@example.com" adds a comment to the public key so you can identify which key is which when you have several. Not security-relevant; just labeling.

ssh-keygen prompts:

1. Where to save the key. Default is ~/.ssh/id_ed25519. Accept the default unless you have a reason to put it elsewhere.
2. A passphrase. Optional. Encrypts the private key on disk so it can't be used by someone who steals the file. For interactive use, pick a strong passphrase. For automation that needs unattended access, leave it empty (or use ssh-agent / Pageant to cache the unlocked key in memory).

The result: two files in ~/.ssh/:

• id_ed25519 — the private key. Permissions 600 (read/write by you only).
• id_ed25519.pub — the public key. Permissions 644 (world-readable is fine).

If your server doesn't support Ed25519 (very old SSH server software), fall back to:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

-b 4096 gives a 4096-bit RSA key, which is currently strong against any realistic adversary. Don't use shorter RSA keys (-b 2048 is the bare minimum; -b 1024 is broken).

Step 2: Install the public key on the server

You need to get the public key only onto the server, in the user's ~/.ssh/authorized_keys file. Three ways:

Option A — ssh-copy-id (easiest, requires password access first):

ssh-copy-id alice@sftp.example.com

Prompts for your password, then appends your public key to ~alice/.ssh/authorized_keys on the server. The next connection won't need a password.

Option B — manual upload via the server's admin UI. Most managed SFTP platforms (including Files.com) have a "paste your public key" field in the user settings. Open ~/.ssh/id_ed25519.pub in a text editor, copy the contents (one long line starting with ssh-ed25519), paste into the admin UI.

Option C — manual upload over an existing SSH session. If you can already SSH into the server, append the key manually:

# On your local machine:
cat ~/.ssh/id_ed25519.pub | ssh alice@sftp.example.com 'cat >> ~/.ssh/authorized_keys'

In all three cases, only the public key (.pub file) goes to the server. Never copy the private key anywhere; it stays on your machine.

Step 3: Connect with the private key

The OpenSSH CLI tools (ssh, sftp) automatically look in ~/.ssh/ for keys and try them in order. If your key is at ~/.ssh/id_ed25519, just connect:

sftp alice@sftp.example.com

No password prompt — the key auth happens transparently.

If your key is in a non-default location, point at it explicitly:

sftp -i ~/keys/sftp-prod.key alice@sftp.example.com

For graphical clients, the configuration varies:

• FileZilla — Edit → Settings → SFTP → Add key file. Then Site Manager → New Site → Logon Type: Key file.
• WinSCP — Site → Advanced → SSH → Authentication → Private key file. WinSCP converts OpenSSH-format keys to its .ppk format automatically. See our import-ssh-keys-winscp walkthrough.
• Cyberduck — Bookmark → SSH Private Key.

Common gotchas

"Permission denied (publickey)" — but the key is right.

Almost always one of three things:

1. 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's in the server's authorized_keys.
2. Permissions on the server are wrong. ~/.ssh/ must be 700; ~/.ssh/authorized_keys must be 600 and owned by the user. SSH refuses to use keys if these are world-writable.
3. The server's SSH daemon is configured for password-only auth. Check /etc/ssh/sshd_config for PubkeyAuthentication yes.

"The key is loaded but it's not being tried."

OpenSSH checks ~/.ssh/id_* by default. If your key has a non-standard name, either rename it or specify with -i on the command line, or add an entry to ~/.ssh/config:

Host sftp.example.com
    User alice
    IdentityFile ~/keys/sftp-prod.key

Now sftp sftp.example.com finds the right key automatically.

Private key permissions too open.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

ssh refuses to use a private key with world-readable permissions. Fix:

chmod 600 ~/.ssh/id_ed25519

Different keys for different servers.

Common pattern — separate keys for work, personal, and per-server credentials. Use ~/.ssh/config to map server to key:

Host work-prod
    HostName sftp.example.com
    User alice
    IdentityFile ~/.ssh/work-prod-ed25519
    IdentitiesOnly yes

Host personal
    HostName home.example.org
    User alice
    IdentityFile ~/.ssh/personal-ed25519
    IdentitiesOnly yes

IdentitiesOnly yes tells OpenSSH "only use the key I specified, don't try every key in ~/.ssh/." Saves you from getting locked out if a server's failed-login limit kicks in after trying the wrong keys first.

When to use SSH keys (and when passwords are fine)

Use SSH keys when:

• The connection is non-interactive (cron jobs, CI/CD, scheduled SFTP transfers, server-to-server replication).
• You're rotating credentials with any regularity — keys are scriptable to rotate, passwords aren't.
• A security review is coming up. Key-based auth answers most of the auth questions auditors ask.
• You're managing multiple users and want a finite revocation path. Remove a key from authorized_keys; done.

Passwords are acceptable when:

• The connection is one-off interactive use by a human who'd rather type a password than manage a key file.
• The server doesn't support key auth (some legacy FTPS-only systems).
• You're on a shared machine where private-key storage is awkward.

For production automation: keys, always.

The modern way

Files.com is the File Orchestration Platform we'd recommend for SFTP workflows in 2026. SSH key authentication is native:

• Generate keys in the admin UI, or import existing public keys. The platform stores them per-user; you download the private key once.
• Per-user keys — each user can have multiple keys (production key, backup key during rotation, dedicated automation key).
• Audit logging on every key-authenticated connection, so you can answer "who connected and what did they do" after the fact.
• MFA, SSO with SAML/SCIM, IP allowlisting layered alongside key auth for defense-in-depth.

Start a free Files.com trial — no credit card, provisioned in about 10 minutes.

For teams that must run SFTP infrastructure inside their own datacenter, the free ExaVault on-premise appliance ships SSH key auth pre-configured from a self-hosted VM image.

FAQ

What is an SSH key?

An SSH key is a cryptographic key pair — a private key that stays on your machine and a public key that goes on the server. SSH uses them for authentication: the server verifies your public key signature against the private key you hold, without the private key ever transiting the network.

How is an SSH key different from a password?

Passwords are a shared secret — both you and the server know them. SSH keys are asymmetric — only you have the private key, and the server only needs the public key (which doesn't reveal the private key). Keys are stronger against guessing (no realistic adversary cracks Ed25519), don't transit the network, and enable passwordless automation.

What's an Ed25519 key vs an RSA key?

Ed25519 is a modern elliptic-curve key type. Small (256-bit private key), fast to generate and verify, currently considered best-practice. RSA is the older option, requires 4096 bits for equivalent strength to Ed25519. Use Ed25519 for new keys unless your server is too old to support it.

Can I have multiple SSH keys?

Yes — you can have as many keys as you want. Common patterns include one key per server, one per role (work / personal), or one per automation job. Use ~/.ssh/config with IdentityFile and IdentitiesOnly yes to map specific servers to specific keys.

Where should I store my private key?

~/.ssh/id_ed25519 (or id_rsa) by default. Permissions must be 600 (chmod 600). The private key file should never leave your machine, never get committed to source control, and never get copied to the server.

How do I set up passwordless SFTP?

Generate a key pair with ssh-keygen -t ed25519, install the public key in the server's ~/.ssh/authorized_keys (or paste it into the platform's admin UI), and connect with sftp — no password needed. See the step-by-step above.

What if my private key has a passphrase?

Then you need to enter the passphrase every connection, or load the key into an SSH agent (ssh-add on macOS/Linux, Pageant on Windows) to cache it in memory for the session. Most SSH clients integrate with the agent automatically; for automation that runs unattended, generate keys without a passphrase.

What's ssh-keygen and where does it come from?

ssh-keygen is the key-generation utility bundled with OpenSSH — the SSH implementation that ships with every Linux distribution, macOS, and modern Windows. If you have ssh installed, you have ssh-keygen. The same tool generates keys, displays fingerprints, converts between formats, and updates known_hosts.

Is using SSH keys really more secure than passwords?

Yes, in two ways. First, key cryptography is far stronger than any practical password — Ed25519 is computationally infeasible to brute-force, while password-guessing attacks are very real. Second, keys don't get phished, leaked in breaches, or typed into the wrong window. The remaining risk is your private key file itself — protect it with file permissions and (optionally) a passphrase.

Can I use the same SSH key for multiple servers?

Yes. Install the same public key on as many servers as you want. The same private key on your machine authenticates to all of them. This is the standard pattern for engineers who connect to many machines.