SSH login slow troubleshoot Techniques

[Siju George]

Hi,

My OpenBSD 3.9 on an amd64 is very very slow for SSH login.

Could some one give me steps I can follow to troubleshoot the problem?

I pinged differrent computers from a linux machine Below are the Statistics



Pinging OpenBSD 3.9 - This is the system that shows the trouble



# ping -c 5 172.16.2.25
PING 172.16.2.25 (172.16.2.25) 56(84) bytes of data.
64 bytes from 172.16.2.25: icmp_seq=1 ttl=255 time=0.102 ms
64 bytes from 172.16.2.25: icmp_seq=2 ttl=255 time=0.110 ms
64 bytes from 172.16.2.25: icmp_seq=3 ttl=255 time=0.119 ms
64 bytes from 172.16.2.25: icmp_seq=4 ttl=255 time=0.115 ms
64 bytes from 172.16.2.25: icmp_seq=5 ttl=255 time=0.114 ms

--- 172.16.2.25 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.102/0.112/0.119/0.005 ms

===

Pinging a FreeBSD 6.1 System

# ping -c 5 172.16.2.26
PING 172.16.2.26 (172.16.2.26) 56(84) bytes of data.
64 bytes from 172.16.2.26: icmp_seq=1 ttl=64 time=0.121 ms
64 bytes from 172.16.2.26: icmp_seq=2 ttl=64 time=0.108 ms
64 bytes from 172.16.2.26: icmp_seq=3 ttl=64 time=0.103 ms
64 bytes from 172.16.2.26: icmp_seq=4 ttl=64 time=0.118 ms
64 bytes from 172.16.2.26: icmp_seq=5 ttl=64 time=0.108 ms

--- 172.16.2.26 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3999ms
rtt min/avg/max/mdev = 0.103/0.111/0.121/0.013 ms

===

Pinging a Debian Etch

# ping -c 5 172.16.2.0
PING 172.16.2.0 (172.16.2.0) 56(84) bytes of data.
64 bytes from 172.16.2.0: icmp_seq=1 ttl=64 time=1.72 ms
64 bytes from 172.16.2.0: icmp_seq=2 ttl=64 time=0.092 ms
64 bytes from 172.16.2.0: icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from 172.16.2.0: icmp_seq=4 ttl=64 time=0.372 ms
64 bytes from 172.16.2.0: icmp_seq=5 ttl=64 time=0.096 ms

--- 172.16.2.0 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.092/0.476/1.725/0.633 ms

=

Pinging a Debian Sarge

# ping -c 5 172.16.2.1
PING 172.16.2.1 (172.16.2.1) 56(84) bytes of data.
64 bytes from 172.16.2.1: icmp_seq=1 ttl=64 time=0.215 ms
64 bytes from 172.16.2.1: icmp_seq=2 ttl=64 time=0.101 ms
64 bytes from 172.16.2.1: icmp_seq=3 ttl=64 time=0.100 ms
64 bytes from 172.16.2.1: icmp_seq=4 ttl=64 time=0.107 ms
64 bytes from 172.16.2.1: icmp_seq=5 ttl=64 time=0.105 ms

--- 172.16.2.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.100/0.125/0.215/0.046 ms

===

Except to the OpenBSD 3.9 system ( 172.16.2.25 ) I can logon to all
other *nx systems very fast.
OpenBSD 3.9 on amd64 seems to be very slow.

Could Some one help me troubleshoot it?

dmesg below

Thankyou so much

KInd Regards

Siju

OpenBSD 3.9 (GENERIC) #462: Thu Mar  2 03:52:16 MST 2006
   [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 1039593472 (1015228K)
avail mem = 879325184 (858716K)
using 22937 buffers containing 104165376 bytes (101724K) of memory
mainbus0 (root)
cpu0 at mainbus0: (uniprocessor)
cpu0: AMD Athlon(tm) 64 Processor 3400+, 2193.99 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3D
NOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative
pci0 at mainbus0 bus 0: configuration mode 1
pchb0 at pci0 dev 0 function 0 ATI RS480 Host rev 0x10
ppb0 at pci0 dev 1 function 0 ATI RS480 PCIE rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 5 function 0 ATI Radeon XPRESS 200 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pciide0 at pci0 dev 17 function 0 ATI IXP400 SATA rev 0x80: DMA
pciide0: using irq 11 for native-PCI interrupt
pciide0: port 0: device present, speed: 1.5Gb/s
wd0 at pciide0 channel 0 drive 0: ST3120827AS
wd0: 16-sector PIO, LBA48, 114473MB, 234441648 sectors
wd0(pciide0:0:0): using BIOS timings, Ultra-DMA mode 6
pciide0: port 1: device present, speed: 1.5Gb/s
wd1 at pciide0 channel 1 drive 0: ST3120827AS
wd1: 16-sector PIO, LBA48, 114473MB, 234441648 sectors
wd1(pciide0:1:0): using BIOS timings, Ultra-DMA mode 6
pciide1 at pci0 dev 18 function 0 ATI IXP400 SATA rev 0x80: DMA
pciide1: using irq 5 for native-PCI interrupt
ohci0 at pci0 dev 19 function 0 ATI IXP400 USB rev 0x80: irq 4,
version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: ATI OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 4 ports with 4 removable, self powered
ohci1 at pci0 dev 19 function 1 ATI 

Re: SSH login slow troubleshoot Techniques

[Otto Moerbeek]

On Wed, 30 Aug 2006, Siju George wrote:

 Hi,
 
 My OpenBSD 3.9 on an amd64 is very very slow for SSH login.
 
 Could some one give me steps I can follow to troubleshoot the problem?

First on the openbsd machine check reserve name lookup of the client
machine you're coming from.
 
Also check how the ip of the openbsd machine resolves on the
client machine. It might have multiple (IPv6?) ip's, some of which are
unreachable. ssh -v might give more clues on that.

-Otto

Re: SSH login slow troubleshoot Techniques

[Darren Tucker]

On Wed, Aug 30, 2006 at 05:54:31PM +0530, Siju George wrote:
 My OpenBSD 3.9 on an amd64 is very very slow for SSH login.
 
 Could some one give me steps I can follow to troubleshoot the problem?

There's a few suggestions here: http://www.openssh.com/faq.html#3.3

From your description, my guess would be that the delay is due to the
server attempting to do a reverse name lookup on the client's IP address
(you can test this quickly by putting it into the server's host into the
/etc/hosts file).

If none of that helps, try running the client in debug mode (ssh -vvv ...)
and see where the pauses are.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Re: SSH login slow troubleshoot Techniques

[Siju George]

On 8/30/06, Jonas Thambert [EMAIL PROTECTED] wrote:

Check your resolv.conf/hosts file. Might be reverse-lookup that
fails.



Bull's eye! you hit it right on target Jonas.

The 3.9 had an outdated nameserver entry.
I updated it and it logs in through SSH real fast :-)

Thanks a million :-)))

Kind Regards

Siju

Re: SSH login slow troubleshoot Techniques

[Breen Ouellette]

Siju George wrote:

Hi,

My OpenBSD 3.9 on an amd64 is very very slow for SSH login.


As already mentioned, if reverse lookup doesn't work your login will 
pause for a substantial amount of time before you are prompted.


Assuming this is a network under your control, if your LAN is small you 
could just update the hosts files on your machines. If you have more 
than a few machines on the network, or a heterogeneous network where it 
isn't as simple as copying around a hosts file, you might want to look 
into using DNS internally. There have been a few times where my ISP has 
had DNS trouble which downed large numbers of their customers, but my 
machines were able to continue right along with no problems because of 
my internal DNS server. There's a little more work involved in setting 
it up, but once you read the man page for named and the BIND 9 
Administrator Reference Manual (free PDF download) it comes together 
pretty quickly. I use an invalid TLD of .int to make sure I don't 
collide with a domain in the outside world, which has never failed me 
for internal use.


You may even want to use DHCP to assign static IPs by using host 
declarations which assign a fixed-address to each host based on the MAC 
address. But I digress.


Breeno

Re: SSH login slow troubleshoot Techniques

[Peter N. M. Hansteen]

Siju George [EMAIL PROTECTED] writes:

 My OpenBSD 3.9 on an amd64 is very very slow for SSH login.

One very common cause of slow response to ssh login requests is some
sort of error in name resolution.  Reverse lookups which do not
complete or does not return the expected result is one of several
conditions which could lead to the observed symptoms.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/
First, we kill all the spammers The Usenet Bard, Twice-forwarded tales
20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds