Introduction

com.jcraft.jsch.JSchException: UnknownHostKey means JSch tried to open an SSH connection but did not trust the server's host key. That is not a random library failure; it is SSH doing its job and refusing a server identity it cannot verify.

Why JSch Throws It

SSH clients keep a known_hosts list of trusted server keys. When JSch connects, it compares the remote server's presented host key against that trust store. If the key is missing or different from the stored value, JSch raises UnknownHostKey.

That protects against man-in-the-middle attacks. A client that accepted any unknown key silently would be convenient, but it would also be much less secure.

The Correct Fix

Load a trusted known_hosts file and make sure it contains the server's host key:

1import com.jcraft.jsch.JSch;
2import com.jcraft.jsch.Session;
3
4JSch jsch = new JSch();
5jsch.setKnownHosts("/home/app/.ssh/known_hosts");
6
7Session session = jsch.getSession("user", "example.com", 22);
8session.setPassword("secret");
9session.connect();

If the host key for example.com is already in that file and matches what the server presents, the connection succeeds.

How to Add the Host Key Safely

The secure approach is to retrieve the server's fingerprint out of band, verify it with the server owner or infrastructure team, and then add it to known_hosts. Once the key is trusted, JSch can validate future connections automatically.

In other words, the fix is not "turn the check off." The fix is "teach the client which host key is correct."

The Tempting but Risky Shortcut

You can disable strict host-key checking:

session.setConfig("StrictHostKeyChecking", "no");

That avoids the exception, but it also removes an important security check. It is acceptable only in throwaway test environments where you understand the risk. It is a poor default for production SFTP or SSH code.

Host Key Changed Versus Host Key Missing

There are two different situations:

• the host key was never known
• the host key changed and no longer matches the stored value

The second case is more serious. A missing key may just mean first contact. A changed key may indicate server reprovisioning, reinstallation, or an active security problem. Treat that difference carefully.

Debugging Tips

If you believe the key should already be trusted, check:

• whether JSch is loading the expected known_hosts file
• whether the hostname in code matches the entry in the file
• whether the server was rebuilt and now has a new key
• whether you are connecting through a different alias or IP than the one stored

These mismatches are common in containerized or multi-environment deployments.

It is also worth remembering that SFTP uses SSH underneath, so the same trust rules apply there. A file-transfer workflow that fails with UnknownHostKey is still an SSH host-verification problem first, not a file-transfer parsing problem.

Seeing it that way makes troubleshooting much faster.

It also keeps the fix appropriately security-focused.

Common Pitfalls

• Disabling host-key checking instead of fixing trust setup.
• Forgetting to call setKnownHosts.
• Storing the key for one hostname and connecting with another.
• Ignoring the difference between an unknown key and a changed key.
• Treating SSH trust failures as purely application bugs.

Summary

• 'UnknownHostKey means the SSH server's identity is not trusted yet.'
• JSch expects a valid known_hosts entry for the target host.
• The secure fix is to verify and store the correct host key.
• 'StrictHostKeyChecking=no avoids the error but weakens security.'
• A changed host key deserves more caution than a first-time unknown key.