Vysoka latencia pri pripojeni cez ssh
Dusan Zatkovsky
msk_conf na seznam.cz
Pondělí Září 10 20:38:58 CEST 2007
Zdravim.
Dnes som spozoroval zaujimavy ukaz, ktory ma do krvy vytaca.
Na 3 strojoch z 4 cakam cca 40s, kym dostanem login prompt z jedneho servera.
K zmene doslo v priebehu weekendu, kedy som na serveri ( debian etch )
upgradol kernel z 2.6.18 na 2.6.21 z backports. Netusim vsak, ci je to
sposobene priamo tymto, pretoze som sa po upgrade 2 dni nenalogoval.
Chova sa to tak, ze z 3 strojov A,B,C ( debian etch / 2.6.18 ) na server S
(debian etch / 2.6.21) cakam cca 40s, nez sa ma ssh opyta na heslo. Detto
pomocou publickey. Zo stvrteho stroja D ( centos 4 ) dostavam login prompt
okamzite.
Stroj A je moj domaci stroj. B a D mam v praci, maju spolocny router a linku,
dns, whatever..., C je vmware debian etch beziaci priamo na tom serveri ( tym
padom vylucujem linku ).
Co som (ne)zistil ( logy, dlhsie ):
SERVER:
------
user na server: /usr/sbin/sshd -d -p 12345
debug1: sshd version OpenSSH_4.3p2 Debian-9
debug1: read PEM private key done: type RSA
...
debug1: Bind to port 12345 on ::.
...
debug1: inetd sockets after dupping: 3, 3
Connection from A.A.A.A port 60689
debug1: Client protocol version 2.0; client software version OpenSSH_4.3p2
Debian-9
debug1: match: OpenSSH_4.3p2 Debian-9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9
debug1: permanently_set_uid: 103/65534
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
=== server LAG 40s ===
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes128-cbc hmac-md5 none
...
debug1: userauth-request for user USER service ssh-connection method none
...
Failed publickey for USER from A.A.A.A port 60689 ssh2
...
debug1: PAM: password authentication accepted for USER
...
debug1: Setting controlling tty using TIOCSCTTY.
CLIENT:
-------
user na A: USER na localhost:~$ ssh -vvv -p 12345 USER na S.S.S.S
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to S.S.S.S [S.S.S.S] port 12345.
debug1: Connection established.
debug1: identity file /home/USER/.ssh/identity type -1
debug3: Not a RSA1 key file /home/USER/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
... opakuje sa cca 10x ...
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/USER/.ssh/id_rsa type 1
debug1: identity file /home/USER/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2
Debian-9
debug1: match: OpenSSH_4.3p2 Debian-9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9
debug2: fd 3 setting O_NONBLOCK
==== client LAG 10s ====
debug1: Miscellaneous failure
No credentials cache found
==== client LAG 20s ====
debug1: Miscellaneous failure
No credentials cache found
==== client LAG 10s ====
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
...
debug1: Authentications that can continue: publickey,password
...
debug1: Next authentication method: password
USER na S.S.S.S's password:
debug3: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
...
Pozeral som na spojenie wiresharkom, spojenie sa nadviaze v pohode, ostane
to stat az niekde daleko za syn/synack/ack, takze to bude priamo v ssh.
Z centos-u sa pripajam pomocou OpenSSH_3.9p1, OpenSSL 0.9.7a, na debianoch
OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006 a klienty som nijak
neupgradoval. Skusal som aj zmazat kluce na klientoch, zmazat cely ssh,
zmazat kluce v agentovi, stale rovnaky vysledok.
Rad by som sa opytal, ci sa s tym uz niekto stretol. Nerad by som totiz siel
laborovat a downgradovat kernel na serveri a zistil, ze chyba je niekde inde.
Dns-ko na serveri chodi v pohode, reverzom to nebude, ostatne sluzby su bez
latencii.
Any ideas?
Dik.
--
Dusan
Další informace o konferenci Linux