Ubuntu – SSH – Software caused connection abort for single login

puttysshUbuntu

I'll give a full background here, not sure how relevant some of it will be but it can't hurt…

So I had a VM running ubuntu server 13.10 that I recently upgraded 14.04 LTS.

After the upgrade, it appeared that I was unable to ssh into the machine. Login via the local console was fine, and ssh out was okay.

After some fiddling, I discovered that ssh only fails for one particular username. Using a second username proved successful.

I have tried multiple ssh clients and each time I receive the same error for that one user:

Software caused connection abort.

Now, from what I gather this comes from Windows itself, so I ask you, what possible reasons for this could there be?

PuTTY logs show the public key authentication succeeding, and then suddenly for no apparent reason, disconnecting:

Event Log: Access granted
Outgoing packet #0x8, type 90 / 0x5a (SSH2_MSG_CHANNEL_OPEN)
...
Outgoing raw data
...
Event Log: Network error: Software caused connection abort

I've tried this with multiple ssh clients, from multiple Windows machines, across three different sites, and the result is always the same. One user works fine, the other fails, so that would suggest something wrong with the Ubuntu box no?

UPDATE

So, following Chirag64's suggestion, ssh 127.0.0.1 connects fine, however ssh <baduser>@127.0.0.1 fails with the same error message.

I've checked group memberships, authentication and user shell, which all match up with the working user.

su baduser allows me to change to that user, and make outgoing ssh connections however, an ssh connection to loopback using current user fails.

It just seems to be incoming connections to that one user for some reason or another.

Best Answer

"Software caused connection abort" means that the server is dropping the connection, so it probably wouldn't matter which client program you're using.

The first thing to check is filesystem permissions for the user on the Ubuntu server. Check the permissions for the user's home directory, the user's .ssh directory, and the files within the .ssh directory. Compare them to the same permissions for user that is working. The OpenSSH server is pretty picky about these permissions, and in some configurations it won't let a user connect if it's possible that someone else modified the user's files.

If that doesn't solve the problem, and you have superuser access to the Ubuntu server, you could run a debug instance of the SSH daemon and see what it logs when it gets a connection for this user:

/path/to/sshd -ddd -p 10022

This will run a copy of sshd listening to port 10022. It won't put itself in the background. When you connect to it with your client, it'll print debugging information to your terminal. Hopefully, the debugging information will give you a better idea of why it's dropping the connection.

If you still can't figure out the problem, you could try running sshd through strace:

strace -f /path/to/sshd -ddd -p 10022

strace will print the system calls being performed by the sshd program. The last few system calls executed by sshd before it drops the connection might give you an idea what it was checking at the time.

Related Question