SSH host keys are how an SFTP server proves it is really itself, and not an impostor sitting in the middle. When your client connects, the server shows its host key, and your client checks that key against the one it saved the first time. If the two match, you are talking to the same server as last time. If they do not match, your client stops and warns you, because something has changed — and that something might be an attacker.

Think of it like calling a friend who saves your number. The first time you call, they save it. Every call after that, their phone says it is you before they pick up. A host key works the same way: the first connection saves the server's identity, and every connection after that confirms it.

Host keys are also where a lot of SFTP setups quietly go wrong. Rotate a key without telling your partners and every one of their connections breaks at once. Never rotate it and you leave the same key in place for years, which is its own risk. This post explains what host keys are, how your client checks them, and what good key discipline looks like.

What Is an SFTP (SSH) Host Key?

An SSH host key is a pair of cryptographic keys that belongs to the server itself. There are two halves: a private key the server keeps secret, and a public key the server hands out to anyone who connects. The server uses the private half to sign a message; your client uses the public half to confirm the signature could only have come from the holder of the private key. That is the whole trick — only the real server can sign in a way the public key will accept.

This is different from the keys you might use to log in. A user key proves you are who you say you are. A host key proves the server is who it says it is. Both can be in play on the same connection: the host key checks the server, then your username and password (or your user key) checks you.

The first time your client connects, it receives the server's public host key and saves it. On every later connection, the client compares the key the server presents against the saved copy. Same key, the connection goes through. Different key, the client raises a flag.

A host key is built with one of a few algorithms — the math used to make the key pair. The common ones are RSA, ECDSA, and Ed25519. RSA is the old standard and works almost everywhere. Ed25519 is the modern choice: shorter keys, faster checks, strong security. If you are standing up a new server and your clients support it, prefer Ed25519.

How SSH Host Keys Work

When your SFTP client opens a connection, the server presents its host key before you ever type a password. Your client looks that key up in a local list of servers it already trusts. On Mac and Linux that list is a file called known_hosts in your .ssh folder; on Windows it lives in the same place under your user profile. Each line in the file is one server and the key it is supposed to use.

Three things can happen:

• The key matches the saved one. Your client recognizes the server and connects without bothering you.
• The server is brand new. Your client has never seen it, so there is nothing to compare against. It shows you the key's fingerprint — a short summary of the full key — and asks if you want to trust it. Say yes and it saves the key for next time.
• The key changed. The server is presenting a key that does not match what your client saved. Your client refuses to connect and warns you loudly.

That last case is the one that matters most. A changed key can mean something innocent — the server was rebuilt, or an admin rotated the key on purpose. It can also mean an attacker has slipped a fake server in front of the real one to capture your login and your files. Your client cannot tell the difference, so it stops and makes you decide. That pause is the whole point: it is the moment that blocks a man-in-the-middle attack, which is the name for an attacker who quietly sits between you and the server, relaying traffic while reading it.

Why SSH Host Keys Matter

Without host keys, your client would have no way to tell the real server from a fake one. It would happily send your username, your password, and your files to whoever answered the connection. Host keys close that hole. Here is what they buy you:

• They stop man-in-the-middle attacks. An impostor server cannot produce the right signature, so your client catches it before any credentials leave your machine.
• They confirm you reached the right server. Every connection lands on the same machine you trusted the first time, not a look-alike.
• They protect the data in transit. Because the server is verified before the transfer starts, the encrypted SSH session you build on top of it actually protects your files instead of protecting a conversation with an attacker.
• They satisfy security reviews. Strong server authentication is a baseline expectation in most security and compliance frameworks, and host keys are how SFTP delivers it.

Managing and Verifying SSH Host Keys

The safe habit is to know a server's host key fingerprint before you connect for the first time, so you are not blindly trusting whatever shows up. You get that fingerprint from a trusted source — the server administrator hands it to you, or your provider publishes it. The command ssh-keyscan <hostname> fetches the key a server is presenting so you can compare its fingerprint against the one you were given. If the two do not match, do not connect; confirm with whoever runs the server first.

A few practices keep host key management from turning into firefighting:

• Keep the known_hosts file clean. Remove entries for servers you no longer use so a stale key cannot quietly authorize a connection you did not intend.
• Rotate keys on a schedule, and warn partners first. Replacing a host key now and then limits how long a single key is exposed. The catch is that every client has the old key saved, so rotating without notice breaks every partner connection at once. Tell them before, not after.
• Publish fingerprints with SSHFP DNS records. An SSHFP record stores a server's host key fingerprint in DNS. When DNS is protected with DNSSEC, clients can look up the expected fingerprint automatically instead of trusting the key by hand on the first connection.
• Automate verification where you can. Hand-checking fingerprints across dozens of partners invites mistakes. Tooling that verifies keys for you removes the human error.

Troubleshooting SSH Host Key Issues

Host key errors are common, especially anywhere servers get rebuilt or moved often. The ones you will actually see:

• "Host key has changed." The server's key no longer matches what your client saved. It might be a routine rotation or a rebuilt server — or it might be an attack. Do not click through it. Confirm the new key with the server's administrator before you accept it.
• "Host key verification failed." Your client refused to connect because the key did not match. Once you have confirmed the change is legitimate, update the saved key in your known_hosts file and try again.
• Adding a key after an expected change. When you know a key changed for a good reason — say, a server migration — fetch the new key and append it to your list with ssh-keyscan <hostname> >> ~/.ssh/known_hosts. Verify the fingerprint matches what the administrator gave you before you trust it.
• A weak or aging key. An older RSA or DSA key may fall short of current standards. Replace it with a modern Ed25519 key and notify your partners so they can save the new one.

SFTP Host Keys on a Modern Platform

Most of the pain in this post comes from one thing: a server you run yourself. You generate the host keys, you store them, you rotate them, you chase every partner when one changes, and you keep the known_hosts housekeeping straight across the whole fleet. None of that work moves files. It is the overhead of operating the server.

Files.com is the cloud-native File Orchestration Platform: one platform that replaces the stack of legacy tools IT teams run to move files — SFTP and FTP servers, MFT suites, file-sharing apps, and the scripts holding them together. It speaks every protocol, connects to 50+ cloud and on-prem systems, automates transfers, and keeps a complete audit trail. The SFTP server is a managed part of that platform, so the host keys are managed too.

Files.com publishes its host key fingerprints for your partners to verify, handles rotation as a platform operation, and stands behind real server authentication — there is no box for you to patch when the next OpenSSH advisory lands. Your partners connect with the same SFTP clients and the same logins they already use; the server identity they verify is one you no longer have to babysit. Every connection is logged in a complete audit log, which is exactly what a security review asks to see.

If SFTP is new to you, our explainer on what SFTP is and how it works covers the protocol from the ground up.

To see managed SFTP in practice, explore Files.com's FTP and SFTP support or start a free trial — no credit card, live in minutes.