SSHJ连接远程Linux服务器抛UserAuthException，求助排查故障

Hey there! It’s super frustrating when one tool connects smoothly with your credentials but another throws auth errors—let’s break down why your SSHJ setup is hitting UserAuthException: Exhausted available authentication methods, and fix it:

1. JDK 8u151’s Default Cryptographic Policy Limits #

Java 8 Update 151 comes with limited cryptographic strength policies enabled by default. This blocks access to older or specific encryption algorithms that PuTTY might automatically use (like certain password hashing or key exchange methods). Since PuTTY isn’t bound by Java’s policy restrictions, it can connect where SSHJ can’t.

Fix: #

Install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK 8u151. This removes the algorithm restrictions and lets SSHJ use the same cryptography suite as PuTTY.

2. SSHJ’s Default Authentication Chain Skips Password Auth Early #

By default, SSHJ tries multiple authentication methods in order (e.g., public key first, then password). If your server rejects the initial methods (like if you don’t have a public key configured), SSHJ might exhaust all attempts before even trying password auth—while PuTTY typically prioritizes password auth right away.

Fix: #

Explicitly force password authentication in your code to bypass the default chain. Here’s a quick example:

SSHClient sshClient = new SSHClient();
// Note: Use a proper host key verifier in production, not this test-only one!
sshClient.addHostKeyVerifier(new PromiscuousVerifier()); 
sshClient.connect("your-server-ip");

try {
    // Directly invoke password authentication
    sshClient.authPassword("your-username", "your-password");
    // Proceed with your SSH operations here
} finally {
    sshClient.disconnect();
}

3. Missing Support for Older Key Exchange (KEX) Algorithms #

PuTTY is more lenient with older, less secure KEX algorithms (like diffie-hellman-group1-sha1) that SSHJ disables by default. If your server only supports these legacy algorithms, SSHJ can’t negotiate a connection handshake.

Fix: #

Manually add support for older KEX algorithms in your SSHJ configuration:

sshClient.getConfig().setKeyExchangeFactories(Arrays.asList(
    new DHG1SHA1.Factory(),       // PuTTY-compatible older KEX
    new DHG14SHA1.Factory(),
    new DHG14SHA256.Factory()     // More secure modern alternative
));

4. Host Key Verification Mismatch #

PuTTY caches host keys after your first connection, so it doesn’t re-validate them. SSHJ, however, strictly checks host keys by default. If your server uses a key type restricted in JDK 8u151 (like DSA), SSHJ will reject the connection outright.

Fix: #

• For testing purposes only, add a verifier to accept the server’s key (never use this in production):

  sshClient.addHostKeyVerifier((hostname, port, key) -> true);
  

• Or configure SSHJ to prioritize supported key types (like RSA or ECDSA) that JDK 8u151 allows.

5. Terminal Type/Environment Variable Differences #

PuTTY sends a default terminal type (like xterm) and certain environment variables that some servers expect for successful authentication. SSHJ might not send these, leading the server to reject the connection.

Fix: #

Set the terminal type explicitly in your code:

sshClient.setTerminalType("xterm");

Start with checking the JCE policy files first—it’s the most common culprit for JDK 8u151 and SSH library issues. Then test explicit password authentication to rule out method ordering problems.

内容的提问来源于stack exchange，提问作者Saikat