Login (10sec timeout) SSH

C

cami

Jungspund
Hallo,

ich habe eine CentOS 5.5 Root-Server den ich per SSH verwalte. Nun habe ich folgendes Problem: Wenn ich mich mit den Server per SSH verbinde, dann benötigt er ~10sec um mir meine Shell aufzumachen. Es ist egal ob ich den Login per Username/pwd oder per SSH-Key mache, 10sec Wartezeit. Es ist einfach nervig und kostet nur Zeit.
Nun hab ich google schon bemüht und meine sshd_config angepasst und "UseDNS no" eingetragen, SSH restartet, etc. Keine Verbesserung.
Die Namensauflösung an sich läuft und auch IPs per nslookup abfragen läuft.

Also für mich sieht das wie ein DNS-Problem aus, aber die Namensauflösung per nslookup läuft und auch die reverse Auflösung via ip und nslookup liefert die richtigen Ergebnisse in einer normalen Geschwindigkeit. Ich bin ziemlich ratlos woran es noch liegen kann.

Gruß cami

# $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

Port 22
Protocol 2
SyslogFacility AUTHPRIV
PermitRootLogin yes
PermitEmptyPasswords no
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
X11Forwarding yes
UseDNS no
Subsystem sftp /usr/libexec/openssh/sftp-server
 
Verbinde dich doch mal per ssh und setzt noch -vv (very verbose), da sollte drin stehen, was er in den 10 Sekunden macht. (Zur Not kann man sogar noch ein weiteres v dranhängen, dann wirds aber spammy.)
 
Hmmm, also ich denke dieser Teil hier ist Interessant:

Code:
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied


debug1: Next authentication method: publickey

Ok, nicht der sshd-Server war schuld, sondern mein Client hier, ich hab in der lokalen ssh_config: GSSAPIAuthentication no eingetragen und nun klappt der Login sehr schnell.

thx
 
Zuletzt bearbeitet:
Hm magst du mal das ganze Verbindungs-Geraffel posten/pastebinnen? Natürlich annonymisiert.
 
Kannst Du nicht ueberpruefen, ob es an DNS liegt, indem Du mal die IP-Adresse benutzt zum Login?
 
GSSAPIAuthentication yes
Code:
user@laptop:~$ ssh -v server
OpenSSH_5.3p1 Debian-3ubuntu5, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /home/user/.ssh/config
debug1: Applying options for index2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/suer/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'x.x.x.x' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:49
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied


debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.utf8
Last login: Thu Mar 17 11:16:50 2011 from x.x.x.x

GSSAPIAuthentication no
Code:
user@laptop:~$ ssh -v index2
OpenSSH_5.3p1 Debian-3ubuntu5, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /home/user/.ssh/config
debug1: Applying options for index2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to x.x.x.x [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'x.x.x.x' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:49
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.utf8
Last login: Thu Mar 17 13:04:37 2011 from x.x.x.x
 
@rikola es machte keinen Unterschied ob ich die IP oder den Namen oder nen Alias benutzt habe.
 
Zuletzt bearbeitet:
@rikola es machte keinen Unterschied ob ich die IP oder den Namen oder nen Alias benutzt habe.
Die anderen Beitraege sind mir wohl dazwischen geraten, aus denen ist das ja auch ersichtlich. Ist Dein Problem denn jetzt geloest?
 
Naja, aber die Methoden verhandeln beide, eigentlich müsstest dus auch auf dem Server ausschalten können..
 

Ähnliche Themen

SSH nicht mehr erreichbar nach fail2ban / disabling root login

SSH mit Public Key "und" Passwort

Mysteriöser 11.4 Absturz - Maschine läuft, SSH und vor Ort Login unmöglich

OpenSSH 4.2 Zugriff unterschiedlicher Benutzer mit PublicKey

OS X SSH bereit machen

Zurück
Oben