我在另一个网络上有一台 Solaris 10 服务器。我可以 ping 它并远程登录它，但 ssh 无法连接。PuTTY 日志中没有任何有趣的内容（它们都协商到 ssh v2），然后我得到
"Event Log: Network error: Software caused connection abort".
ssh 肯定正在运行：
svcs -a | grep ssh
online 12:12:04 svc:/network/ssh:default
以下是服务器 /var/adm/messages 的摘录（匿名）
Jun 8 19:51:05 ******* sshd[26391]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer
但是，如果我通过 telnet 连接到该机器，我可以在本地登录 ssh。我也可以顺利通过 ssh 连接到该网络上的其他（非 Solaris）机器，因此我认为这不是网络问题（不过，由于我离这里有几百英里远，所以我不能确定）。
服务器的防火墙已禁用，所以这应该不是问题
root@******** # svcs -a | grep -i ipf
disabled Apr_27 svc:/network/ipfilter:default
有什么想法我应该开始检查什么吗？
更新： 根据以下反馈，我已在调试模式下运行 sshd。以下是客户端输出：
$ ssh -vvv root@machine -p 32222
OpenSSH_5.0p1, OpenSSL 0.9.8h 28 May 2008
debug2: ssh_connect: needpriv 0
debug1: Connecting to machine [X.X.X.X] port 32222.
debug1: Connection established.
debug1: identity file /home/lawrencj/.ssh/identity type -1
debug1: identity file /home/lawrencj/.ssh/id_rsa type -1
debug1: identity file /home/lawrencj/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.0
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
以下是服务器输出：
root@machine # /usr/lib/ssh/sshd -d -p 32222
debug1: sshd version Sun_SSH_1.1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: Bind to port 32222 on ::.
Server listening on :: port 32222.
debug1: Bind to port 32222 on 0.0.0.0.
Server listening on 0.0.0.0 port 32222.
debug1: Server will not fork when running in debugging mode.
Connection from 1.2.3.4 port 2652
debug1: Client protocol version 2.0; client software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer
debug1: Calling cleanup 0x4584c(0x0)
这句话似乎很适合：
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
答案1
如果您使用的是基于密钥的身份验证，请检查服务器上的 .ssh/authorized_keys 文件。我遇到了同样的问题，设置访问权限的人粘贴的密钥中有换行符。删除换行符可以解决问题，但您可以通过将 authorized_keys 文件移开进行测试，或者先选择密码身份验证，看看是否遇到同样的问题：
ssh -o PreferredAuthentications=password username@hostname
答案2
尝试完全禁用 GSSAPI：
GSSAPIAuthentication no
您是否在 sshd_conf 中的允许用户列表中？
答案3
您可能能够通过执行标志（如果您想让原始端口保持运行，则可能使用标志来指定另一个端口）来获取更多有用的调试信息
sshd，-d然后-p使用sshd客户端连接到它ssh -v。
更新：您的问题似乎与网络有关，而不是与身份验证有关。您可以看到对话双方的连接都已重置。您可以咨询相关网络团队，看看是否有中间网络节点（例如防火墙）导致了问题。
答案4
由于您说 SSHv2 是协商的，我怀疑这与密钥交换问题有关。
目前还没有找到关于此的任何很好的描述；有这个PuTTY参考尽管。
您应该尝试在服务器上捕获数据包，以查看 SSH 通信在哪里停止。
您还可以尝试“ ssh -v”来查看客户端看到了什么错误。