[K12OSN] slow SSH login problem
John Lucas
mrjohnlucas at gmail.com
Wed Feb 7 17:01:56 UTC 2007
On Wednesday 07 February 2007 12:07, David Whitmer wrote:
> A minor problem recently appeared on one of our school's K12LTSP servers.
>
> Beginning about two weeks ago, logging into this server remotely via
> SSH began to take about 2 minutes (this used to take only a few
> seconds). Once logged in, everything works okay over the SSH
> connection. In fact, I'm not having any other problems with this
> server.
>
> This server is running K12LTSP 6.0 (the version based on FC6). Our
> school has some other K12LTSP servers, all running v5 (FC5), and none
> of those are experiencing this particular SSH login problem.
>
> I normally manually run yum update once a week on our servers.
>
> Does anyone have any suggestions on what I can check? Or ideas on
> what the problem might be? (I'll have time to try some things this
> evening.)
>
Are you by any chance using LDAP or NIS authentication? If an authentication
service is under-performing, logins will become painful.
DNS might be another problem. If you have more than one nameserver listed
in /etc/resolv.conf, try testing the responsiveness of each one listed with:
dig @nameserverIP www.google.com
where "nameserverIP" is replaced by the IP address of each of the nameservers
listed in /etc/resolv.conf. It may be that the you are failing your way
through each nameserver in turn before you are finally able to resolve names
(or falling though altogether). Turning off DNS lookups for sshd
(/etc/ssh/sshd_config "UseDNS no") will work around the problem, but you
really should fix DNS if that is the problem.
It might be something changed during your updates, but I would think there
would be lots of folks with the same problem. I use K12LTSP 5 and Fedora Core
6 and haven't seen this problem.
Finally (and most basically) you may be experiencing link saturation on your
WAN link or another network problem that is increasing your latency. If you
can ping (not blocked by firewall), try pinging in *both* directions and
check the return times, variation, and packet loss. It would be nice if you
had a baseline for these numbers prior to the problem, but if the problem is
bad enough, it will probably be obvious. Pinging your firewall from your
remote location would show any WAN numbers that may turn up the problem even
if your firewall blocks reaching internal hosts.
--
"History doesn't repeat itself; at best it rhymes."
- Mark Twain
| John Lucas MrJohnLucas at gmail.com |
| St. Thomas, VI 00802 http://mrjohnlucas.googlepages.com/ |
| 18.3°N, 65°W AST (UTC-4) |
More information about the K12OSN
mailing list