ssh 连接停止于“debug1:SSH2_MSG_KEXINIT 已发送”

50 ssh

我已将 ssh 端口号从 22 更改为 2222 之前设置的连接到默认 ssh 端口 22 没问题 我已正确映射路由器上的 NAT

当我尝试调试它时

ssh -v -p2222 www.example.com
Run Code Online (Sandbox Code Playgroud)

我收到此错误挂起

debug1: SSH2_MSG_KEXINIT
Run Code Online (Sandbox Code Playgroud)

以下是所有调试日志

bob@server:~$ ssh -v -p2222 www.example.com
OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to www.example.com [100.100.100.100] port 2222.
debug1: Connection established.
debug1: identity file /home/bob/.ssh/identity type -1
debug1: identity file /home/bob/.ssh/id_rsa type -1
debug1: identity file /home/bob/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu1.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
debug1: SSH2_MSG_KEXINIT sent
Connection closed by 100.100.100.100
Run Code Online (Sandbox Code Playgroud)

就像连接关闭一样,我在网络内外的几台机器上使用了 gnome-terminal、putty、securecrt 仍然遇到相同的错误

小智 39

我刚刚在 XEN 主机上发生过这种情况。我从另一个主机复制了这个主机,按照惯例,我在执行此操作后删除了 /etc/ssh 中的主机密钥,认为稍后会生成新的主机密钥。但这从未发生过,并且 sshd 在没有主机密钥的情况下愉快地启动了。当尝试 ssh 到该主机时,它会在 SSH2_MSG_KEXINIT 之后退出。我所要做的就是创建主机密钥,在基于 debian 的机器上是这样完成的:

dpkg-reconfigure openssh-server
Run Code Online (Sandbox Code Playgroud)


小智 22

我遇到了这个问题,并通过将目标路由器/防火墙和目标主机上的 MTU 设置为与源主机相同(1500)来解决它。


小智 10

SSH2_MSG_KEXINIT 不是错误。它只是告诉您它正在开始 ssh 密钥交换过程。

如果另一端此时正在关闭连接,显然它出于某种原因不喜欢你:-) 来自远程端的日志可能包含有关连接突然关闭的原因的信息。(例如 TCP 包装器)

  • 在 CentOS6.4 docker 容器上遇到这个问题。生成密钥需要: `ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key` 在 /etc/ssh/sshd_config 中添加“UsePAM no”。如果不是安全问题,则“PermitRootLogin yes”。 (2认同)

小智 10

我遇到了同样的问题,当我更改 sshd_config 中的端口并重新启动 sshd 服务时,sshd 感到困惑,当我最终查看服务器日志(看起来你不能)时,sshd 抱怨端口已经存在使用,netstat 同意,并且 ps 显示了 sshd 服务的多个实例正在运行。我杀死了它们并再次启动 sshd,并且能够连接。我发誓我尝试重新启动来解决问题,但我想不会,因为这可能会解决问题。

长话短说,应该在端口 2222 上侦听以对您进行身份验证的 sshd 并不是实际侦听的,而是另一个 sshd 进程。如果你也有和我一样的问题。