我在另一个networking上有一台Solaris 10服务器。 我可以ping它并telnet到它，但ssh不连接。 腻子日志不包含任何利益（他们都谈判ssh V2），然后我得到
"Event Log: Network error: Software caused connection abort". ssh是defintely运行的：
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到框，我可以在本地login到SSH。 我也可以在那个networking上ssh到其他（非Solaris）机器，所以我不相信这是一个networking问题（尽pipe我离我几百英里远，我不能确定）。
服务器的防火墙被禁用，所以不应该是一个问题
root@******** # svcs -a | grep -i ipf disabled Apr_27 svc:/network/ipfilter:default
任何想法，我应该开始检查？
更新：基于下面的反馈，我已经在debugging模式下运行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 [XXXX] 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
如果您使用基于密钥的身份validation，请检查服务器上的.ssh / authorized_keys文件。 我有同样的问题，并设置访问权限的人已经粘贴的行中断的键。删除换行解决了问题，虽然你可以通过移动authorized_keys文件的方式，或通过挑选密码authentication首先看看你是否得到同样的问题：
ssh -o PreferredAuthentications=password username@hostname
尝试完全禁用GSSAPI：
GSSAPIAuthentication no
你在sshd_conf允许的用户列表吗？
你可以通过执行带-d标志的sshd来得到一些更有用的debugging信息（如果你想让原来的sshd运行，可能还需要-p标志来指定另一个端口），然后用你的ssh -v连接到它ssh -v客户端。
更新：它看起来像你的问题是networking相关，而不是身份validation相关。 您可以看到对话双方都重置了连接。 您可以与相关的networking团队进行核对，以确定是否存在导致问题的中间networking节点（例如防火墙）。
这很有趣，我有同样的问题。 只有我可以ssh从本地networking，但不使用vpn时。
May 11 18:03:10 servername sshd [14733]：[ID 800047 auth.crit]致命：从套接字读取失败：由对等方重置连接
我从来没有得到提示一个电压。 会议很快就结束了。
自从你说SSHv2协商以来，我怀疑是和密钥交换问题有关。
目前还找不到任何好的描述; 有一个PuTTY参考虽然。
您应该尝试在服务器上捕获数据包以查看SSH通信停止的位置。
您也可以尝试“ ssh -v ”来查看客户端看到的错误。
这是TCP Wrappers（hosts.deny）造成的99％的时间。 你可能需要在那里允许你的IP地址：
/etc/hosts.deny
它从本地主机工作的原因是因为127.0.0.1可能在那里（或通过/etc/hosts.allow）。
您的sshd叉会处理连接（即使在debugging运行）。 在我看来，就像孩子即将与系统的身份validation机制进行交互一样，他们正在悄然死去。 这是通常检查UID，GID并运行PAM的时间。 你的服务器是否使用LDAP或NIS +？
最好在正常运行的服务器上运行debugging，看看接下来应该怎么做（使用vimdiff或diff）。
最近有一个类似的问题，当一个小组有太多的成员（所有成员的长度约为500-600个字符）。 虽然这是在Linux上。
注意，当运行服务器进行debugging时，请指定-ddd（三重debugging）以获取更多信息。
你说目标主机在另一个networking中。 而且“服务器防火墙已禁用”。
networking和目标networking之间是否有防火墙或任何types的数据包过滤设备？
这是值得做一个traceroute看看两个networking之间的东西。
还要确保在传输过程中不丢失任何数据包。 ping一个简单的testing可以帮助您找出是否有任何networking问题。
在我的例子中，查看/ var / log / messages显示我有太多会话打开（受PAM限制）：Aug 21 18:05:43 nv20 pam_limits [13325]：用户login次数过多（最多20次）
几个ctrl-D的后来和ssh再次工作…
我刚刚解决了一个类似的问题，同样的症状：断开后：
debug1: SSH2_MSG_KEXINIT sent.
在两个端口上运行ssh服务器，22和另一个未公开的端口。 我可以使用端口22连接，但在主机密钥交换之前，不能使用上述突然断开的端口。
事实certificate，端口22 sshd作为root运行，而sshd作为用户ubuntu运行的其他端口。 显然，ubuntu用户不能读取私有主机密钥，如/var/log/auth.log所示：
error: Could not load host key: /etc/ssh/ssh_host_rsa_key error: Could not load host key: /etc/ssh/ssh_host_dsa_key fatal: No supported key exchange algorithms
命令“sudo netstat -nap | grep ssh'为端口22和另一个端口（已编辑）返回了2个不同的进程：
$ sudo netstat -nap | grep ssh tcp 0 0 0.0.0.0:other port 0.0.0.0:* LISTEN 17620/sshd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 31160/sshd tcp6 0 0 :::other port :::* LISTEN 17620/sshd tcp6 0 0 :::22 :::* LISTEN 31160/sshd
显示端口22上的ssh服务器使用进程＃ 31160，而另一个端口使用端口＃ 17620 。
和'ps -eaf | grep ssh“显示一个进程以root身份运行，另一个进程以ubuntu（已编辑）运行：
$ ps -eaf | grep ssh ubuntu 17620 1 0 Apr25 ? 00:00:00 /usr/sbin/sshd root 31160 1 0 08:35 ? 00:00:00 /usr/sbin/sshd
为了解决这个问题，我必须杀死以ubuntu运行的进程（ kill 17620 ），并使用命令“sudo /etc/init.d/ssh restart”重新启动ssh服务器。
我不知道这是怎么发生的，但是在试图重现这个问题之后，我发现我可能试图重新启动sshd而不是root。 它工作，但新的端口是由Ubuntu的用户主持：
$ /etc/init.d/ssh restart Could not load host key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_dsa_key * Restarting OpenBSD Secure Shell server sshd start-stop-daemon: warning: failed to kill 31884: Operation not permitted Could not load host key: /etc/ssh/ssh_host_rsa_key Could not load host key: /etc/ssh/ssh_host_dsa_key
如果这是我所做的，我就会因为忽略这些错误信息而被咬伤。 尽pipe如此，这可能被认为是一个错误，因为服务器不能正常重新启动，而不杀死Ubuntu的运行sshd。
对于那些想知道的，我使用另一个端口，而不是端口22，以防止在我的所有服务器上的端口22上的大多数连接尝试，然后阻止端口22使用防火墙。 这很简单，但工作，并允许我从任何IP地址连接。
这个问题可以通过在腻子无法访问的机器上从控制台/terminal提示符运行以下2个命令来解决：
$ sudo apt-get –purge删除openssh-server
$ sudo apt-get install openssh-server
第一个命令完全卸载openssh服务器使用清除，不像autoremove，离开configuration文件后面。 第二个命令重新安装opnessh服务器
现在尝试再次进入机器。