2

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.

  • Try sshing into the system from the same system. Something like ssh 127.0.0.1. – Chirag Bhatia - chirag64 Apr 22 '14 at 13:48
  • ssh 127.0.0.1 connects fine from the good user, ssh <baduser>@127.0.0.1 returns "Write failed: Broken pipe" – Ahhhhbisto Apr 22 '14 at 13:54
  • In your /etc/ssh/sshd_config file, try these settings: ClientAliveInterval 120 ServerAliveInterval 120 TCPKeepAlive no – Chirag Bhatia - chirag64 Apr 22 '14 at 14:26
  • The ServerAliveInterval 120 line caused the server to refuse new connections. Removing that and leaving the ClientAliveInterval 120 and TCPKeepAlive no made no change I'm afraid. – Ahhhhbisto Apr 22 '14 at 14:40
1

"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.

  • So running a debug instance proved useful. I'm getting debug3: safely_chroot: checking '/' debug3: safely_chroot: checking '/home/' debug3: safely_chroot: checking '/home/<baduser>' bad ownership or modes for chroot directory "/home/<baduser>" I can't place the error in permissions or ownership though. User/Group are both the username, and permission set is 0755. – Ahhhhbisto Apr 22 '14 at 18:57
  • So, looking a little further, the user in question had been added to the sftpusers group, hence the attempt to chroot. Of course, chroot requires the dir owner to be root. – Ahhhhbisto Apr 22 '14 at 19:12
0

I've had similar issues and everytime, it appeared to be an issue with .bashrc Try clearing any custom config from .bashrc and .bash_profile.

edit: for that specific user (/home//.bashrc)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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