SSH to home server is slow

D

drhowarddrfine

As an experiment, I put a box at a business I own's back room and hooked it up to their DSL which is some basic business package but probably no better than residential DSL, meaning about 1.5Mb down and 384K up on ATT. It shares the router with a POS system that's unused at night. When I got back home and SSH'ed into it, there were times when it would hang to where I'd have to quit out of SSH and try again. Other times it would work better but still might take 10 seconds before asking for my password. And then other times I can log in right away. It's not too far off from logging in to HostGator, though.

I did a traceroute on it. It goes the same 12 hops each time and then I get nothing but '*' after that. I don't know if that router is set to not respond to pings or not. If it matters, I'm on cable.

This is the first time I've tried it this way so is this a matter of that's how it is or should I be looking into some settings somewhere?

The router is just a Dlink DIR655. I've done no thinking about this at all since I just hooked it up last night, tried it out, and went to bed and I can be pretty network stupid. So I'm just looking for any constructive comments before I bother digging into this some more.
 
The box you're SSH'ing into has a rather limited upstream. If this upstream is saturated with other traffic your SSH session can be slow or even fail.
 
Was there a high load on the server? I spend time working on a cluster and when I try to ssh into a compute node and someone is running a big job, I will see the same problems you described.

Is there any type of packet prioritization on the router? Do other servers behind the router have similar problems? I have a home router running a simple linux distribution and once in a blue moon dhclient, if I recall correctly, will start using 100% cpu and cause similar problems.

If none of these problems are the cause, you could try turning on compression. Maybe something like

Code: 
Host `hostname`
Compression yes

in ~/.ssh/config on the client side.
 
drhowarddrfine said:
As an experiment, I put a box at a business I own's back room and hooked it up to their DSL... It shares the router with a POS system that's unused at night.
Click to expand...

Since you mention you aren't that knowledgeable with network, I would like to just bring up that if the POS system does any credit card transactions, placing a non-scanned system in the same network segment as the POS could affect the business PCI compliance status.

As for the slowness, 384Kb up should be enough for SSH (I ssh into systems with much less than that). Most likely the uplink is being saturated by something else, like the POS system sending updates somewhere?

Two suggestions are, enable compression on your SSH session to help a bit with the limited bandwidth issue, and see if you can monitor the bandwidth usage on the router. As for the '*' during traceroutes, not all routers/systems are set to respond to ping so you would end up with unidentified hops.
 
drhowarddrfine said:
... and SSH'ed into it, there were times when it would hang to where I'd have to quit out of SSH and try again. Other times it would work better but still might take 10 seconds before asking for my password ...
Click to expand...

Did you try to disable the DNS lookup of the ssh daemon. The inability of DNS resolution may cause the described blocking. In /etc/ssh/sshd_config of the server search for the line #UseDNS yes and replace it by UseDNS no. Then restart sshd.
 
@rolfheinrich may be onto it. I first logged in but it took 30 seconds or so. After disabling DNS, it was only about three seconds. I'm going to wait an hour or so to make sure it wasn't some fluke.
 
Yes, slow connect to a machine (via ssh) is usually (or very often) caused by that machine being unable to to get an answer to a DNS query for the DNS name of the connecting machine, as already mentioned by rolfheinrich.
Some people will argue that the correct way to fix this (in 2012) is to make sure that the machine you connect to has a working DNS resolver configuration.
 
Hm. Then you've brought up something interesting Warren. It's been consistently fast since I added that line to the conf file but, yes, it was inconsistent before that.
 
You must log in or register to reply here.
Back
Top