Why does programmatic SSH to server using ganymed-ssh-2 results in Key Exchange error?

I'm using the ganymed-ssh-2 Java library to create a connection from one AWS EC2 to another (in the same VPC) and the 'connect()' command gives the following error:

java.io.IOException: Key exchange was not finished, connection is closed.
    at ch.ethz.ssh2.transport.KexManager.getOrWaitForConnectionInfo(KexManager.java:75)
    at ch.ethz.ssh2.transport.TransportManager.getConnectionInfo(TransportManager.java:169)
    at ch.ethz.ssh2.Connection.connect(Connection.java:759)
    at ch.ethz.ssh2.Connection.connect(Connection.java:628)
    at bravura.autoperf.executor.SSHExecutor.connectTo(SSHExecutor.java:156)
    at bravura.autoperf.executor.SSHExecutor.runRemoteSSHCommand(SSHExecutor.java:57)
    at bravura.autoperf.executor.SSHExecutor.runRemoteSSHCommand(SSHExecutor.java:141)
    at bravura.autoperf.util.Utilities.runCommandRepeatedly(Utilities.java:614)
    at bravura.autoperf.test.Server.getServerDetails(Server.java:233)
    at bravura.autoperf.test.Server.<init>(Server.java:127)
    at bravura.autoperf.test.Server.<init>(Server.java:65)
    at bravura.autoperf.util.Utilities.getClientServer(Utilities.java:499)
    at bravura.autoperf.manager.RunSetupManager.<init>(RunSetupManager.java:69)
    at bravura.autoperf.manager.ExecutionManager.runTests(ExecutionManager.java:171)
    at bravura.autoperf.manager.ExecutionManager.main(ExecutionManager.java:64)
Caused by: java.io.IOException: Cannot negotiate, proposals do not match.
    at ch.ethz.ssh2.transport.ClientKexManager.handleMessage(ClientKexManager.java:123)
    at ch.ethz.ssh2.transport.TransportManager.receiveLoop(TransportManager.java:572)
    at ch.ethz.ssh2.transport.TransportManager$1.run(TransportManager.java:261)
    at java.lang.Thread.run(Thread.java:748)

Calling code:

    Connection connection = new Connection(host);
    connection.connect();

This is before the 'authenticateWithPublicKey()' method has had a chance to be called.

The NACL and relevant security group have been opened up for port 22 traffic for the VPC CIDR range (which both instances are in). The Route Table routes all VPC CIDR traffic locally.

I can manually ssh with no issues.

(OS is Amazon Linux 2 fwiw)

Thanks for any help.

Solution

Reading the exception output it would suggest that one the key exchange algorithms supported on the server do not match any of those supported by the client.

Caused by: java.io.IOException: Cannot negotiate, proposals do not match.

You can easily see what the server supports by executing the command line

ssh -vv user@host

Most likely cause is either a cipher, HMAC or key exchange algorithm. I would take a guess at key exchange as there has been a lot of movement in those over the years and so modern servers may be configured for stronger key exchange after the discovery of vulnerabilities like Logjam

To actually fix the problem would require an upgrade in the client library to something that supports the algorithm that is missing.