Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a Solaris 10 server on another network. I can ping it and telnet to it, but ssh doesn't connect. PuTTY log contains nothing of interest (they both negotiate to ssh v2) and then I get

"Event Log: Network error: Software caused connection abort".

ssh is defintely running:

svcs -a | grep ssh
online         12:12:04 svc:/network/ssh:default

Here's an extract from the server's /var/adm/messages (anonymised)

Jun  8 19:51:05 ******* sshd[26391]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer

However, if I telnet to the box, I can login to ssh locally. I can also ssh to other (non-Solaris) machines on that network fine so I don't believe that it's a network issue (though, since I'm a few hundred miles away, I can't be sure).

The server's firewall is disabled, so that shouldn't be a problem

root@******** # svcs -a | grep -i ipf
disabled       Apr_27   svc:/network/ipfilter:default

Any ideas what I should start checking?

Update: Based on the feedback below, I've run sshd in debug mode. Here's the client output:

$ 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

And here's the server output:

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)

This line seems a likely candidate:

debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
share|improve this question
    
Can you post your /etc/ssh/sshd_config ? It may be that you have disabled all the authentication mechanisms –  Dave Cheney Jun 24 '09 at 10:01
add comment

12 Answers

up vote 3 down vote accepted

Check your .ssh/authorized_keys file on the server if you are using key based authentication. I had the same issue, and the person who had set up access had pasted the key with line breaks in. Removing the line breaks fixed the issue, although you can test by moving the authorized_keys file out of the way, or by picking password authentication first and seeing if you get the same issue:

ssh -o PreferredAuthentications=password username@hostname
share|improve this answer
    
Genius! I don't know why it doesn't work by default but specifying the password authentication solved the problem. –  ideasasylum Jun 26 '09 at 10:13
    
Actually, I've just checked /.ssh/known_hosts and there was a duplicate key for the server. I removed that and normal ssh root@server is working again. Not entirely sure fi/how/why that was the problem but glad to have ssh access. –  ideasasylum Jun 26 '09 at 10:15
add comment

Try to completely disable GSSAPI:

GSSAPIAuthentication no

Are you in allowed user list in sshd_conf?

share|improve this answer
add comment

You might be able to get some more useful debugging information by executing sshd with the -d flag (and possibly the -p flag to specify another port if you want to leave the original sshd running), and then connecting to it with your ssh -v client.

Update: It looks like your issue is network related rather than authentication related. You can see that both sides of the conversation had their connection reset. You might check with the relevant network team to see if there is an intermediate network node (e.g. a firewall) that is causing the problem.

share|improve this answer
    
Depending on what ssh client you're using, you may be able to pass multiple -v's to get greater verbosity –  Matt Simmons Jun 11 '09 at 19:47
    
Thanks for the tip! Very useful. I've included the output in the question above as comments aren't formatted. –  ideasasylum Jun 12 '09 at 13:26
add comment

This is interesting, I have the same issue. Only I can ssh from the local network but not when using vpn.

May 11 18:03:10 servername sshd[14733]: [ID 800047 auth.crit] fatal: Read from socket failed: Connection reset by peer

I never get prompted for a pw. The sessions dies to quickly.

share|improve this answer
add comment

I suspected something to do with key-exchange problems since you say SSHv2 is negotiated.

Could not find any good description on that yet; there is this one PuTTY reference though.

you should try a packet capture on the server to see where the SSH communication stops.

You can also try "ssh -v" to see what errors the client sees.

share|improve this answer
add comment

This is 99% of the time caused by TCP Wrappers (hosts.deny). You probably need to allow your IP address in there:

/etc/hosts.deny

The reason it works from localhost is because 127.0.0.1 is probably allowed in there (or via /etc/hosts.allow).

share|improve this answer
    
This seems like a great suggestion but /etc/hosts.deny doesn't exist and AFAIK the default behaviour is to allow all? –  ideasasylum Jun 12 '09 at 13:26
add comment

Your sshd forks to handle the connection (even on debug run). It seems to me like the child is silently dying as soon as it is about to interact with system's authentication mechanisms. This is about the time when it normally checks for UID, GID, and runs PAM. Does your server use LDAP or NIS+?

It is best to run debug on a properly functioning server and see what should come next (use vimdiff or diff).

I've got very similar issue recently when a group had too much members (the lenght of all members was about 500-600 chars). Although that was on Linux.

Nota bene, when running server for debug, specify -ddd (triple debug) to get more information.

share|improve this answer
add comment

I still think this is a networking problem. Can you describe the topology of the network between the source and destination? Also, can you replicate the problem from other machines? Does "iptables -L -n" return any rules?

share|improve this answer
    
debug1: Connection established. Probably means this is NOT a networking problem. –  Jean Vincent Apr 26 '11 at 8:26
add comment

You say that the destination host is in another network. And that the 'servers firewall is disabled'.

Is there a firewall or any kind of packet filtering device in between your network and destination network.

It would be worth doing a traceroute to see what is in between the two networks.

Also make sure that you are not losing any packets during transmission. A simple test with ping could help you figure out if you have any network issues.

share|improve this answer
add comment

In my case, looking in /var/log/messages showed me I had too many sessions open (limited by PAM): Aug 21 18:05:43 nv20 pam_limits[13325]: Too many logins (max 20) for user

A few ctrl-D's later and ssh was working again ...

share|improve this answer
add comment

I just resolved a similar issue with the same symptom: disconnected after:

debug1: SSH2_MSG_KEXINIT sent.

Running ssh server on two ports, 22 and 'another undisclosed port'. I could connect using port 22 but not using the other port with the above sudden disconnection before host key exchange.

It turned out that sshd for port 22 was running as root while sshd for the other port it was running as user ubuntu. Obviously, the ubuntu user cannot not read the private host key as shown in /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

The command 'sudo netstat -nap | grep ssh' returned 2 different processes for port 22 and the other port (edited):

$ 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

Shows that ssh server on port 22 uses process #31160 while the other port uses port #17620.

And 'ps -eaf | grep ssh' showed that one process was running as root while the other one was running as ubuntu (edited):

$ 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

To solve the problem, I had to kill the process running as ubuntu (kill 17620) and restart the ssh server using the command 'sudo /etc/init.d/ssh restart'.

I don't know for sure how this happened but after trying to reproduce the issue, I found that I may have attempted to restart sshd while not root. It works but the new port is hosted by ubuntu user:

$ /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

If this is what I have done, I was bitten for ignoring these error messages. Nonetheless this may be considered as a bug since the server can no longer be restarted properly without killing the ubuntu-running sshd.

For those who wonder, I use another port instead of port 22 to prevent most connection attempts on port 22 on all my servers and then block port 22 using a firewall. This is simple but works and allows me to connect from any ip address.

share|improve this answer
add comment

This problem can be solved by running the following 2 commands from the console/terminal prompt on the machine which putty cannot access:

$ sudo apt-get --purge remove openssh-server
$ sudo apt-get install openssh-server

The first command completely uninstalls the openssh server using purge, unlike autoremove, which leaves config files behind. The second commands reinstalls the opnessh server

Now try sshing into the machine again.

share|improve this answer
1  
Solaris doesn't use apt-get. –  Michael Hampton Nov 12 '12 at 6:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.