[K12OSN] slow SSH login problem

[John Lucas]

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)                         |