为什么使用 ganymed-ssh-2 到服务器的编程 SSH 会导致密钥交换错误? [英] Why does programmatic SSH to server using ganymed-ssh-2 results in Key Exchange error?

问题描述

我正在使用 ganymed-ssh-2 Java 库创建从一个 AWS EC2 到另一个(在同一 VPC 中)的连接，并且connect()"命令出现以下错误:

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)

调用代码:

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

这是在 'authenticateWithPublicKey()' 方法有机会被调用之前.

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

NACL 和相关安全组已针对 VPC CIDR 范围(两个实例都在其中)的端口 22 流量开放.路由表在本地路由所有 VPC CIDR 流量.

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.

我可以毫无问题地手动 ssh.

I can manually ssh with no issues.

(操作系统是 Amazon Linux 2 fwiw)

(OS is Amazon Linux 2 fwiw)

感谢您的帮助.

推荐答案

阅读异常输出会表明服务器支持的密钥交换算法与客户端支持的任何算法都不匹配.

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.

由:java.io.IOException:无法协商，提案不匹配.

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

ssh -vv user@host

最可能的原因是密码、HMAC 或密钥交换算法.我会猜测密钥交换，因为这些年来发生了很多变化，因此在发现诸如 Logjam

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.

这篇关于为什么使用 ganymed-ssh-2 到服务器的编程 SSH 会导致密钥交换错误?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！