CODEWITHSUNDEEP
javaamazon-web-servicesamazon-ec2ssh
GlorianChris
GlorianChris

Reputation: 227

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.

Upvotes: 1

Views: 6515

Answers (4)

Balamurugan
Balamurugan

Reputation: 11

We plan to use Ganymed 264, but unfortunately, development has been inactive since 2014. We will work on fixing this and aim to share the updated JAR file as soon as possible. Please watch the github for the same.

https://github.com/balaiitm/ganymed264.git

Upvotes: 0

Hassan Raza
Hassan Raza

Reputation: 56

I ran into same issue using ganymed-ssh2 the error was on Ubuntu 20, the ganymed-ssh2 library uses diffie-hellman-group-exchange-sha1, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1 Kex Algos, and Ubuntu have these algos enabled by default:

curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

As mentioned here https://manpages.ubuntu.com/manpages/impish/en/man5/sshd_config.5.html, I enabled the diffie-hellman-group14-sha1 using sshd_config and adding a line KexAlgorithm +diffie-hellman-group14-sha1

Upvotes: 0

Sathyendra Prabhu
Sathyendra Prabhu

Reputation: 31

If your setup is in a secure & controlled environment and if you want to get away from this error then, Comment following 2 entries in /etc/ssh/sshd_config

PermitEmptyPasswords no
MACs <some entry>

and restart the sshd (service sshd restart) This should work

Upvotes: 0

Lee David Painter
Lee David Painter

Reputation: 510

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.

Upvotes: 3

Related Questions