SSH Keys Explained for File Transfer

Somewhere in your organization, there is probably a script that logs into an SFTP server every night and moves files. If that script authenticates with a password, the password is sitting in a file, readable by anyone who can read the script, typed into a protocol conversation every single night, and — if policy forces a password change — capable of silently breaking the job at the worst possible time. Every administrator who inherits one of these scripts eventually asks the same question: there has to be a better way to let a machine log into another machine.

There is, and it is the SSH key pair. Keys are how serious SFTP and SCP automation authenticates: no secret is typed, no secret crosses the network, and access can be granted, restricted, and revoked one key at a time. But keys only deliver those benefits if you understand what the two halves actually do — and most explanations either drown the reader in cryptography or wave their hands entirely.

This article is the plain-words version. By the end you will know what each half of a key pair is for, how a key actually logs you in, what a fingerprint is and why administrators quote them at each other, and exactly why keys beat passwords for unattended transfer jobs. It is the foundation article of our SSH Key Management series — everything else in the series builds on the mental model you get here.

One Identity, Two Halves: What a Key Pair Is

An SSH key pair is two small files that are generated together and mathematically linked. One is the private key — the secret half. The other is the public key — the shareable half. The pair works because of a one-way relationship between them: anything signed with the private key can be verified with the public key, but the public key cannot be used to reconstruct the private key or to forge a signature. You can hand the public key to anyone on earth without weakening the secret half.

The classic analogy is a padlock and its key, and for once the classic analogy is accurate. The public key is a padlock: you can stamp out copies and hand them to every server you want access to. Each server snaps your padlock onto your account. The private key is the one physical key that opens those padlocks. Owning a padlock lets a server recognize you; it never lets the server — or anyone who steals the padlock — impersonate you.

This division of labor produces the single most important rule in all of key management, the rule that everything else in this series depends on:

Notice what this rule implies about setup. When you hear "install your key on the server," what actually gets installed is the public half — appended to a server-side list of accepted keys. The private half stays home. That is why key authentication can be safer than passwords even across untrusted networks: there is no moment, ever, when the secret is in transit.

How a Key Logs You In: A Challenge, Not a Secret

Password login is simple to picture: the client sends the secret, the server compares it to what it has on file. Key login is different in a way that matters. The client never sends the secret at all. Instead, the server issues a challenge — a one-time test that only the holder of the private key can pass.

Here is the sequence in plain words, for an SFTP client connecting to a server:

1. The client connects and the two sides establish an encrypted channel (the server also proves its own identity at this point — that is the host key, a separate topic we cover in host keys and known_hosts).
2. The client says, in effect: "I would like to log in as user transfer-acme, and here is the public key I intend to use."
3. The server checks its list of authorized public keys for that account. If the offered key is on the list, the server replies: "Prove it. Sign this unique, one-time piece of data tied to this session."
4. The client uses the private key to produce a signature over that data and sends the signature back. The signature demonstrates possession of the private key without revealing a single bit of it.
5. The server verifies the signature using the stored public key. If it checks out, the login succeeds.

The diagram below shows the exchange. Follow the arrows and notice which things cross the network: a public key, a challenge, and a signature — never the private key itself.

Two properties of this exchange are worth pausing on, because they are the source of every advantage keys have. First, the challenge is unique per session, so a recorded login cannot be replayed later — the old signature will not match a new challenge. Second, the server ends the exchange knowing the client holds the private key while having learned nothing that would let the server (or an attacker who compromises it) impersonate the client elsewhere. Compare that with a password, which the server necessarily receives in usable form every time you log in.

Fingerprints: A Short Name for a Long Key

A public key is a few hundred characters of base64 text. Humans cannot compare those by eye, and reading one over the phone to a partner would be absurd. So SSH gives every key a fingerprint: a short, fixed-length hash of the public key that acts as its name. If two fingerprints match, the keys are the same; if they differ in even one character, the keys are different. A fingerprint identifies a key the way the last four digits of a card number identify a card — enough to recognize it, nowhere near enough to recreate it, and safe to say out loud.

You will meet fingerprints constantly in transfer work: confirming with a partner that the key they received is the key you sent, checking which key a nightly job is using, matching a line in a server's key list to an entry in your inventory, and verifying a server's identity on first connection. The command that prints a fingerprint is ssh-keygen -l, pointed at a public key file:

$ ssh-keygen -lf nightly-report.pub
256 SHA256:Yq8kT3n0Wb1xR7pVd2mAzcE9fH6uJ4sLgN5oPiQwXk0 nightly-report@batch01 (ED25519)

Read the output left to right: the key's size in bits, the fingerprint itself (the SHA256:... string), the key's comment label, and the key type. When this series talks about "inventorying keys" or "confirming a key with a partner," fingerprints are the unit of conversation. Get in the habit of recording one for every key you create — it costs nothing now and answers questions years later.

Why Keys Beat Passwords for Unattended Transfers

For a human logging in interactively, passwords and keys are both workable. For an unattended job — a scheduled transfer that runs with nobody watching — the comparison stops being close. Here is the honest case, point by point:

• No secret crosses the network. A password is transmitted (inside the encrypted channel) and processed by the server on every login. A private key never travels. A compromised or impersonated server can capture a password and reuse it; it can capture nothing reusable from a key login.
• Not guessable in practice. Password guessing against internet-facing SFTP servers is constant background noise — dictionaries, credential lists, brute force. A properly generated key has no dictionary to try. Attackers scanning your server can hammer at it for the lifetime of the universe without stumbling onto a private key. (Guessing attacks and how to blunt them are covered in our brute-force protection series.)
• Nothing to type means nothing to prompt for. Unattended jobs fail in ugly ways when something unexpectedly asks a question. Key authentication is designed for non-interactive use; there is no prompt to hang on at 2 a.m.
• No scheduled-expiry breakage. Password policies that force periodic changes are built for humans and quietly sabotage machine accounts: the password expires, the job fails, and the on-call admin learns about the policy at 3 a.m. Keys do not expire on a policy clock; they are retired deliberately, on your schedule.
• One key per machine and per job. A password is one secret shared by every script and person who knows it. Keys are naturally per-client: the reporting server gets its own pair, the backup box gets its own, each partner gets their own. Access can then be revoked for exactly one of them without touching the rest.
• Server-side restrictions. A password grants whatever the account can do. A key entry on the server can carry conditions — only from this address, only this operation, no interactive shell. That per-key control is one of the strongest tools in this series, covered in distributing and controlling authorized_keys.

Honesty requires the other side of the ledger, too. Keys shift the burden rather than abolishing it: the private key file is still a secret that must be stored and permissioned correctly, and keys accumulate silently if nobody tracks them — a server can end up trusting keys whose owners left years ago. Keys do not remove the need for management; they make management possible, at a per-key granularity passwords cannot offer. The rest of this series is exactly that management. For a broader comparison of authentication methods across protocols, see our transfer authentication series.

The Two Files on Disk

Concretely, generating a key pair produces two files. With default naming on OpenSSH-style systems they land in the .ssh folder of your home directory — for example id_ed25519 (the private key) and id_ed25519.pub (the public key). The .pub suffix is the entire naming distinction, which is why sloppy handling causes accidents: the file without .pub is the secret.

The public key file is a single line of text, and it is worth seeing one so it stops being mysterious:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFa9k2PqT7wXe0cRuY4mHnB1sLdJ8vZoGxN6iQpM3tE5 nightly-report@batch01

Three space-separated parts: the key type, the key material in base64, and a free-text comment — a label that travels with the key and exists purely for humans. Use the comment deliberately (which job, which machine) and future audits become dramatically easier. The private key file, by contrast, is a multi-line block framed by BEGIN and END OPENSSH PRIVATE KEY markers. You never need to read its contents; you only need to protect them.

What about key types? You will see names like ed25519, ecdsa, and rsa in file names and outputs. Resist the urge to memorize a "best algorithm" — that answer drifts, and chasing it is not the job. The durable guidance: use the current recommended types, which in practice means whatever a current OpenSSH release offers as its default, and keep RSA in your toolkit for older servers and appliances that predate newer types. The generation walkthrough, including the type decision and the passphrase decision, is the subject of generating and storing SSH keys properly.

Where Keys Fit in a Transfer Workflow

SSH keys matter to file transfer because the workhorse transfer protocols ride on SSH. SFTP is a file transfer protocol that runs inside an SSH session; SCP is a copy command that does the same. Authenticate the SSH session with a key and your file transfers are key-authenticated — there is no separate "SFTP key" to manage. (If the relationship between SSH and SFTP is fuzzy, how SFTP works lays it out; SFTP authentication covers the method choices on the server side.)

In a typical transfer setup, the pieces land like this:

• On the client machine — the one initiating transfers — lives the private key, owned by the account the job runs as. Command-line tools like sftp and scp pick it up automatically or via configuration; on Windows, a scheduled-transfer client such as Sysax FTP Automation stores the path to the private key in the connection profile, so every unattended run authenticates the same way.
• On the server lives the public key, attached to a specific account. On OpenSSH servers that means a line in the account's authorized_keys file. On a Windows SFTP server such as Sysax Multi Server, you attach the public key to the account in the server's configuration — same principle, different interface: the server stores public halves and challenges whoever connects.
• In your records lives the fingerprint, the owner, and the purpose — the inventory habit that keeps key sprawl from becoming next year's incident, covered in key rotation and the key inventory.

The table below condenses the comparison you will most often need to make — and to explain to management — when moving a transfer job from password to key authentication.

What Key Pairs Do Not Solve by Themselves

A clear mental model includes the edges. Three things a user key pair does not handle:

It does not verify the server. Your key proves the client's identity to the server. The mirror-image question — is the machine I just connected to really my server, or an impostor? — is answered by a different key pair entirely: the server's host key, which your client checks against a remembered fingerprint. Automation that ignores host keys is automation that can be silently redirected, so treat host keys and known_hosts as the required second half of this article.

It does not manage itself. Keys have no built-in expiry and no central registry. Every key you create will exist until someone deliberately removes its public half from the servers that trust it. Without an inventory and an offboarding habit, key sprawl becomes forgotten access — the exact problem the rotation and inventory habits, and the offboarding sweeps later in this series, exist to prevent.

It does not protect a badly stored private key. The math is unbreakable; a private key sitting world-readable on a shared server is not. File permissions, storage locations, and the passphrase decision are the very next article in the series.

Where to Go Next

Here is the one-minute version to carry forward. An SSH key pair is a secret private half that never leaves its machine and a shareable public half that servers keep. Login is a challenge-and-signature exchange, so no secret ever crosses the network and nothing can be replayed. Fingerprints are short, safe names for keys — the vocabulary of every audit and every partner conversation. For unattended transfer jobs, keys beat passwords on every axis that matters: nothing transmitted, nothing guessable, nothing to expire mid-job, and per-key revocation and restriction on the server.

Next, put the model into practice: generate and store a key properly, then control the server side with authorized_keys. If your immediate goal is moving a scheduled job off passwords, SFTP automation shows where key authentication slots into an unattended workflow.

Frequently Asked Questions