Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a server in a remote location. While connecting to that machine using SSH, it keeps getting disconnected saying:

Read from remote host XXXX: Connection reset by peer
Connection to XXX closed.

I am doubting this as a problem with the Internet connection at our end because ping to that machine shows request time outs in random intervals. I tried even pinging Google which also showed request time out.

How can I confirm that it's a problem with the Internet/what is the actual error?

More info:

We have an VPN tunnel between our network and the remote network. So I can ssh remote machine using one of the local IP that it gains. and tracert to that finishes in 2 hopes with success.

share|improve this question
i know this doesn't really work to solve your problem, but if you find your connection timing out alot, use screen to get your shell back... execute "screen -D -RR" will start a screen session, if you get disconnected, you can re-execute that command it will reconnect you to the existing session on that server. Any program or processes you had will still be running in that session, so you won't lose too much if u get disconnected. also, using screen you can open multiple "windows" on the command line and switch between them. – Roy Rico Sep 17 '09 at 17:42
Thanks Roy. I know about Screen and i am using it for last 1 week. But the disconnect time from server is too shot that I cant even go to screen and type one command. And for the time, I am doing remote desktop to one of the windows machine in remote location and doing ssh from there using Putty. Its little slow, but affordable since no disconnect is happening. – Umesh Sep 18 '09 at 11:39

i would recommend that you use the traceroute command. On windows, it is shortened to 'tracert'

for example, open up the command prompt and type the following (-d means dont do DNS lookups):

tracert -d <your server ip address>

this will give you a list of all the hops that a TCP packet hits along the way to the target. The last successful hop before you get a timeout will give you an idea of where the internet is failing. It could be your wifi, your ISP, or something else.

Another idea is that sometimes the SSH connection can be dropped because the system thinks the connection is idle and that its ok to drop it. This could also be a setting in your modem. But i think traceroute will give you a good idea of the failure point. If you never catch a failure with traceroute, i'd say that perhaps something is activly dropping your idle connection. Look into Keep-Alive type settings in your Wifi Router/DSL modem etc.

But post back your findings and lets see if we can help you figure this thing out.

good luck.

share|improve this answer

I'd advise installing something like smokeping. That'll give you stats over a period of time that you can use to go beat your ISP into providing a half decent service.

share|improve this answer

Run a network capture on your machine while connected to the remote machine. When the disconnect occurs look in the capture for a TCP RST (reset) from the remote machine. If you find it then the problem is with the remote machine. If you don't then the problem is somewhere in the connection between the two.

share|improve this answer
Personally I don't see how ping and tracert are going to help you diagnose the problem. Pings timeout all the time, tracerts fail all the time, routers choose to drop ICMP traffic all the time. None of that means that the path is faulty or that the host that times out or drops a packet or two is the cause of the problem. IMHO the only way to start digging in to this problem is to run a network capture and netstat on one or both sides of the connection and analyze the data that you see in both. – joeqwerty Sep 17 '09 at 15:07
@joeqwerty: I dont know how you came to the conclusion that tracert fails all the time.. Perhaps one or two routers in the middle may not respond, but the trace will reach the target when the net is working and it will fail when it is not. tracert is a good tool to figure out where the path is breaking. Packet capture will not help in this case, unless something is Reseting connection.. keep in mind the OP is not a network admin and going beyond ping/tracert and into packet capture & analysis is a bit complicated. How is packet capture going to help if the path to the target is the problem? – J Sidhu Sep 17 '09 at 16:12

With all due respect, I don't mean that tracert fails every time. I mean that when one host in the path fails to respond to a tracert it doesn't mean that that host is the problem, and if you use tracert a lot you'll see that invariably there always seems to be a host in the path that doesn't respond.

The issue here is with the connection intermittently dropping. If it were down hard than using tracert and ping would be a good choice. Ping and tracert are good triage level tools but they're not going to help discover the cause of intermittent problems. Tracert (as it's name implies) is a tool for tracing the route to a remote host, and by it's nature can tell you if a path does or does not exist. Tracert is not a diagnostic tool that can tell you why a host isn't responding or is dropping packets. The only way to glean that information is to run a network capture on both ends of the connection, and ideally if possible, on each link in the path.

If I run a constant ping and a constant tracert to a remote host and I get a failed ping response from the remote host and at the same moment see an intermediate host in the tracert stop responding, does that mean that that intermediate host is the problem? No it doesn't and there would be now way to correlate the two events unless I was running a network capture on every link in the path and could analyze the data at the packet level.

I was simply suggesting to start the troubleshhoting with the known, measurable components, which are the two hosts at either end of the connection.

I know everyone has their own opinion and my intention is not to start a war, so my apologies if anyone takes offense.

share|improve this answer

Do you have anything in place that might be throttling or rate-limiting incoming SSH connections on the machine, such as iptables (Linux) or inetd.conf (FreeBSD)? What happens if you wait 5 or 15 minutes before retrying the connection?

share|improve this answer
There is no settings like that. I haven't waited and tried. Some times the disconnect rate is too high.In that time I will get mad and will stop the work on that machine. And at night the disconnect ration will be less so that i can work little easily. – Umesh Sep 18 '09 at 11:45

Your Answer


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.