SFTP 连接在“SSH2_MSG_KEXINIT 已发送”处挂起

SFTP 连接在“SSH2_MSG_KEXINIT 已发送”处挂起

我正在努力通过 SFTP 从我的本地服务器连接到我的 AWS 测试帐户。

当我进入我的私人 ssh 密钥的目录并运行时,sftp -v -i <private_key_file> <client>@<hostname>我得到了以下结果:

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to <hostname> [<IP Adress>] port 22.
debug1: Connection established.
debug1: identity file <private_key_file> type 1
debug1: key_load_public: No such file or directory
debug1: identity file <private_key_file>-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version AWS_SFTP_1.1
debug1: no match: AWS_SFTP_1.1
debug1: Authenticating to <hostname>:22 as 'client'
debug1: SSH2_MSG_KEXINIT sent

过了很久我才明白Couldn't read packet: Connection reset by peer.

奇怪的是,当我从同一个本地服务器与我的 AWS 开发账户建立相同的连接时,一切都很顺利。但在 AWS 测试环境中,却无法正常工作。我显然已为位于我的 AWS 测试环境中的客户端分配了另一个公钥,并在上面的命令中引用了新的私钥。

任何帮助都将不胜感激。

答案1

之后 SSH 冻结SSH2_MSG_KEXINIT sent肯定表明 MTU 存在问题。

路径 MTU 发现应该会自动为您确定 MTU。但是,根据中间的防火墙规则和两端的操作系统,这可能不起作用。

如果路径 MTU 发现不起作用,则必须手动设置 MTU。

我建议从 1400 开始,然后上升到仍然有效的最高值。

如何设置 MTU 并使更改持久取决于操作系统。

相关内容