我尝试使用 PuTTY 通过 SSH 连接到我们的服务器，并在输入用户凭据后立即收到此错误：远程端意外关闭了网络连接
我以前能够成功做到这一点，所以服务器端（cPanel）一定发生了一些变化，但我无法确定是什么。有什么建议可以给我指明正确的方向吗？
[编辑以添加日志文件]
Authenticated to ([IP]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug1: console supports the ansi parsing
debug3: Successfully set console output code page from:437 to 65001
debug3: Successfully set console input code page from:437 to 65001
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Mon May 4 19:47:44 2020 from IP-SOURCE
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug3: send packet: type 98
Last login: Mon May 4 19:47:44 2020 from IP-SOURCE
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug3: receive packet: type 98
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: receive packet: type 97
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug3: Successfully set console output code page from 65001 to 437
debug3: Successfully set console input code page from 65001 to 437
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug3: send packet: type 97
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)
debug3: send packet: type 1
debug3: Successfully set console output code page from 65001 to 437
debug3: Successfully set console input code page from 65001 to 437
Connection to IP closed.
Transferred: sent 2288, received 2672 bytes, in 0.5 seconds
Bytes per second: sent 4577.6, received 5345.9
debug1: Exit status 0
答案1
PuTTY 失败的消息是
远端在 USERAUTH_SUCCESS 之后发送了 SSH2_MSG_EXT_INFO
根据源代码https://github.com/github/putty/blob/master/sshverstring.c#L526，PuTTY 知道一些服务器“我们认为远程版本存在 SSH-2 密钥更新错误”. 检测是根据服务器在初次握手期间发送给客户端的版本标识字符串进行的。
SSH-2 重新密钥错误已记录：
PuTTY 的列表不可能是全面的，我相信正在发生的事情是，一些确实有“SSH-2 重新密钥错误”不在PuTTY已知有缺陷的服务器列表中。
就我而言，此故障发生在 Ubuntu 16（“OpenSSH_7.2p2 Ubuntu-4ubuntu2.10”）上，但不发生在较旧的 CentOS 6（“OpenSSH_5.3”）。我进行了一些测试来限制较新的服务器对密钥算法的选择，但尚未找到可以解决 putty 错误的服务器端设置。
与失败的 Ubuntu 服务器版本匹配的 OpenSSH 客户端报告“kex 协议错误：类型 7 序列 73”当服务器报告“debug1：已收到 73 的 SSH2_MSG_UNIMPLEMENTED”。OpenSSH 客户端的默认配置是根本不执行重新密钥。
根据所有这些数据点，我得出以下推断：
- OpenSSH 的重新密钥实现在某些服务器版本（例如 7.2）上存在问题，但默认情况下重新密钥是禁用的，因此问题不明显。
- PuTTY 可以更完整地实现密钥更新，但无法正确检测损坏的服务器。
一些解决方案：
- 使能够连接/SSH/错误/处理 SSH-2 密钥重新交换不当（“在”）以查找受影响的连接配置文件；PuTTY 将确认“远程错误阻止密钥重新交换（超时）”在其事件日志中。
- 找到不受影响的服务器软件版本进行更新。
要测试哪些服务器软件受到影响，您可以设置PuTTY的连接/SSH/Kex/重新密钥前的最大分钟数将其设置为较低的值（例如 1），使其每分钟重新密钥一次。默认值为 60，这意味着连接通常会在 1 小时后失败。