I was working on my rackshack server when I began getting random ssh disconnection. The server would suddenly closes the connection, and for a few minutes, it would continue to reject my login. I can eventually login, but this has happened for a few times.

I am very puzzled about this. I can't figure out why this is happening. Rackshack's network looked fine, so its probably not the network's fault. (ping, webmin, and http also worked, although not at the time of disconnection).

I have checked the diskspace, and it is still only 50% used, so it can't be log file overflow (if this should even be a concern). The CPU usage, free memory, and network usage all looked fine (from a stat program that I have).

Any idea why this happened? Could this be somekind of hacking? Should I be alarmed?

Thanks,

Peter

Hi Peter,

Does sound odd - almost like an IP routing problem, i.e. that your access to your IP address was being redirected to a different server. Do your failed login attempts appear in your log files? If they do, then it's prolly not what I'm whittering on about in this paragraph. If they don't then it would seem like you're accessing a different server when it's failing and might explain why you're being dropped. If this is the problem, then RackShack would seem to be the ones to check their router configuration (especially that someone else isn't using your IP address).

I would suggest trawling your log files at the time you were experiencing the problems, as this might throw up more oddities.

Do you have chkrootkit installed? http://www.chkrootkit.org - just incase.

Oh, another thing you could try is enabling TELNET (temporarily) and TELNET in, shutdown SSH and then run it interactively with debug enabled:

sshd -dd -D

Then connect as you would do normally via SSH and play around until you get thrown off and see what the interactive session had to say about it. After this, don't forget to restart SSH normally and then turn off TELNET and change your passwords ;)

Lastly, I guess it's always possible that you have a dodgy network card.

Sorry that I haven't anything more specific, just a few ideas to check out.

I just reread your post and realised that you don't seem to be having a specific SSH problem, rather a network one, so I'd ignore what I said about TELNET and SSH ;) But I'd be concerned about the issues I raised about the network.

I've just remembered a similar problem we had a while back with one of our web servers with a different provider - that turned out to be an IP routing problem. The subnet we were on was being intermittently routed elsewhere due to a broken router on its last legs.

Jonanthan, thank you so much for your help.

I am still having problem as of now (12 hours later). As you said, it may be ip routing issue. However, I know at least three additional IPs besides my server's main IP is having issue.

I am suspecting that this is a network card turn bad. (there goes my 72 days uptime....)

I am still monitoring the situation to figure out exactly what is wrong.

Thanks again for your help.

Peter

Peter, you didn't turn off your tcp timestamps too, did you? :)

You should do a tcpdump to see what's happening. Look at the packet sequence numbers, flags, and stuff. Good luck.

Thanks for your help, Mark. Sorry for the ignorent question, but how do I check? :blush:

I didn't do any major change to the server, so timestamp settings should have been as before. (on or off)

I ran the command, and it showed lines with this - "<nop,nop,timestamp 630763910 31272>" so I have timestamp turned on. (right?)

Thanks,

Peter

I was just kidding about the timestamps. Someone else had posted that they were saving on transfer by disabling tcp timstamps. In theory, they would get less reliable tcp connections more prone to resets under certain conditions.

I actually meant the tcp flags, such as fin, and rst. Looking at these flags alone (when the connection goes down) would allow you to see if one side was initiating the end of the connection.

Each tcp packet you receive from the remote host will have an ack that contains the byte that it has received up to so far. If this isn't meshing up with the last byte that was sent, then you could identify tcp reliability problems. Some information on this is in the tcpdump man pages.

After rereading your first post, unless you're only allowed one SSH login at a time, it seems like it would be a problem with the SSH daemon. You might try restarting your sshd in debug mode and then looking at your logs. Keep raising the debug mode until you find something. If you don't find something, then try running an strace. Or just recompile. :)

Thanks for your help, Mark.

I sometimes use more than one SSH connection, however, it has been working for 70 days, and I didn't make any changes, so it shouldn't be the ssh server's fault.

The problem seems to have gone away mysteriously again. But I will keep a close eye on it.

Thanks again,

Peter