# [solved] ssh: seltsame Wartezeiten vor Login

## schachti

Seit einiger Zeit beobachte ich auf meinem Gentoo-Desktop sehr seltsame Verzoegerungen beim Login via ssh.

Szenario 1: Ich sitze direkt an der Kiste und logge mich per ssh auf einem anderen Rechner ein: ssh funktioniert ohne Verzoegerung.

Szenario 2: Ich bin von einem anderen Rechner aus per ssh auf meinem Desktop eingeloggt und moechte mich dann per ssh von dort aus auf einem anderen Rechner einloggen. Ich werde direkt nach Absetzen des ssh-Befehls wie gewohnt nach dem Passwort gefragt, gebe es ein - und muss dann ca. 5-7 Sekunden warten, bis ich den Prompt bekomme.

Woran koennte das liegen? Installiert ist net-misc/openssh-4.2_p1.

----------

## dakjo

Guck doch einfach mal mit 'ssh -v' was da passiert.

----------

## schachti

Nach ssh -v -v -v sehe ich nach Eingabe des Passwortes fuer 5-7 Sekunden die folgenden Meldungen, bevor ich zum Prompt komme:

```

Password:

debug3: packet_send2: adding 32 (len 25 padlen 7 extra_pad 64)

debug2: input_userauth_info_req

debug2: input_userauth_info_req: num_prompts 0

debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)

debug1: Authentication succeeded (keyboard-interactive).

debug1: channel 0: new [client-session]

debug3: ssh_session2_open: channel_new: 0

debug2: channel 0: send open

debug1: Entering interactive session.

debug2: callback start

debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-pikIF12430/xauthfile generate unix:10.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null

```

Keine Ahnung, warum da eine Wartezeit von 5-7 Sekunden entsteht...

----------

## chilla

emerge dir testweise mal "dropbear" und lass ihn auf einem anderen Port laufen. Dann vergleiche mal die zeiten von dropbear und openssh, ob dropbear vielleicht ein wenig fixer geht.

----------

## schachti

Wenn auf meinem Desktop dropbear läuft und ich mich von dort aus per dbclient auf einem anderen Rechner einlogge, habe ich diese Verzögerungen nicht. Wenn aber auf meinem Desktop dropbear läuft und ich mich von dort per openssh auf einem anderen Rechner einlogge, habe ich die Verzögerung trotzdem wieder, genauso, wenn ich mich auf dem openssh-Server auf dem Desktop einlogge und von dort aus per dbclient weiter auf den nächsten Rechner.

Wenn ich mich also von Rechner A auf dem Desktop einlogge und von dort aus weiter auf Rechner B, klappt es nur ohne diese 5-7 Sekunden Verzögerung, wenn auf meinem Desktop dropbear als Server läuft und ich mich von dort aus mittels dbclient auf Rechner B einlogge. Sehr seltsam...

Hat jemand eine Idee, woran das liegen könnte? Früher(TM) war das nicht so...

----------

## Deever

Hast du vielleicht zu viele Schlüßel erstellt, die natürlich alle zuerst durchprobiert werden müssen? Verwende gegebenenfalls den 'ssh'-Schalter '-i', um einen Schlüßel anzugeben.

Gruß,

/dev

----------

## schachti

Naja, 2 Schlüssel sollten nicht zuviel sein...

----------

## schrippe

ist das bei jedem anderen rechner so oder immer nur bei einem?

wir hatten das problem mal, das der zu erreichende rechner nen falschen dns eintrag hatte und immer versuchte ein reverse lookup zu machen.

----------

## schachti

Ist mir bisher nur bei dem Rechner aufgefallen.

Der DNS-Eintrag ist jedenfalls korrekt, ausserdem steht in der /etc/ssh/sshd_config auf allen Rechnern UseDNS no.

----------

## think4urs11

Schuß ins Blaue (da ich dropbear noch nie ausprobiert habe)

entweder bringt 

 */etc/ssh/sshd_config wrote:*   

> AddressFamily inet

 

Besserung - oder aber es gibt ein PAM-Problem (nachdem das ganze ja erst *nach* der Passwordeingabe auftritt)

----------

## schachti

 *Think4UrS11 wrote:*   

> 
> 
> entweder bringt 
> 
>  */etc/ssh/sshd_config wrote:*   AddressFamily inet 
> ...

 

Leider nein.

 *Think4UrS11 wrote:*   

> 
> 
>  - oder aber es gibt ein PAM-Problem (nachdem das ganze ja erst *nach* der Passwordeingabe auftritt)
> 
> 

 

Das koennte sein, aber bevor ich jetzt nochmal einen halben Tag mit der Fehlersuche verbringe, lasse ich es so, wie es ist. So oft nutze ich ssh nicht, und wenn ich 3 oder 4 Mal am Tag 5-7 Sekunden laenger warten muss, ist das halt so (ist ueber's Jahr gerechnet weniger, als ich fuer die weitere Fehlersuche braeuchte   :Wink: ).

Danke fuer Eure Tipps.

----------

## Species

Hi,

ich beobachte das selbe Phänomen bei mir schon seit geraumer Zeit auf 5 verschiedenen Rechnern. Bisher ging ich immer davon aus, dass es an Reverse DNS Auflösung liegt, sicher bin ich mir aber nicht. Da es mich nicht weiter stört, halt ein paar Sekunden zu warten, hatte ich bisher wenig Zeit in die Ursachenforschung investiert.

Also, du bist nicht allein  :Wink: 

Grüße

Enrico

----------

## think4urs11

wenns reverse DNS wäre dann würde das *vor* dem Passwortprompt auftreten.

In dem speziellen Fall tritt es aber danach auf.

Evtl. irgendeine seltsame on/off Kombination aus den verschiedenen Authmechanismen.

Bei mir tritt das (auf Holz klopf) bisher nicht auf.

----------

## schachti

Auf Nachfrage hier meine sshd_config des Desktop-Rechners - im Grunde die Default-Konfiguration, mit meinen speziellen Aenderungen am Ende:

```

#       $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $

# This is the sshd server system-wide configuration file.  See

# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented.  Uncommented options change a

# default value.

#Port 22

Protocol 2

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::

# HostKey for protocol version 1

#HostKey /etc/ssh/ssh_host_key

# HostKeys for protocol version 2

#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_dsa_key

# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h

#ServerKeyBits 768

# Logging

# obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

#LogLevel INFO

# Authentication:

#LoginGraceTime 2m

#PermitRootLogin yes

#StrictModes yes

#MaxAuthTries 6

#RSAAuthentication yes

#PubkeyAuthentication yes

#AuthorizedKeysFile     .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

# similar for protocol version 2

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

PasswordAuthentication no

#PermitEmptyPasswords no

# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no

# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication mechanism.

# Depending on your PAM configuration, this may bypass the setting of

# PasswordAuthentication, PermitEmptyPasswords, and

# "PermitRootLogin without-password". If you just want the PAM account and

# session checks to run without PAM authentication, then enable this but set

# ChallengeResponseAuthentication=no

UsePAM yes

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

#PrintMotd yes

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

#UsePrivilegeSeparation yes

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS yes

#PidFile /var/run/sshd.pid

#MaxStartups 10

# no default banner path

#Banner /some/path

# override default of no subsystems

Subsystem       sftp    /usr/lib/misc/sftp-server

#

# Schachti

#

PermitRootLogin no

LoginGraceTime 1m

MaxAuthTries 2

UseDNS no

MaxStartups 5

X11Forwarding yes

AddressFamily inet

```

----------

## think4urs11

setz mal 

X11Forwarding no

----------

## schachti

Hmm, das loest das Problem - allerdings nur teilweise, denn da es sich um meinen Desktop-Rechner handelt, auf dem ich auch von remote aus Anwendungen starten muss, die X benoetigen, kann ich es nicht dauerhaft deaktivieren.

Allerdings scheint das Problem damit identifiziert zu sein...

----------

## psyqil

 *schachti wrote:*   

> 
> 
> ```
> debug2: x11_get_proto: /usr/bin/xauth -f /tmp/ssh-pikIF12430/xauthfile generate unix:10.0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200 2>/dev/null
> ```
> ...

 War das nicht vorher schon klar? Starte ssh doch mal mit -X und/oder -Y...

----------

## schachti

ok, Problem geloest - mit ssh -x (kleines x!) geht es ohne den laestigen Timeout. Danke an alle.

----------

## psyqil

 *schachti wrote:*   

> Hmm, das loest das Problem - allerdings nur teilweise, denn da es sich um meinen Desktop-Rechner handelt, auf dem ich auch von remote aus Anwendungen starten muss, die X benoetigen, kann ich es nicht dauerhaft deaktivieren.

  *schachti wrote:*   

> mit ssh -x (kleines x!) geht es ohne den laestigen Timeout

  *man ssh wrote:*   

> -x      Disables X11 forwarding.

   :Question:   :Question:   :Question: 

----------

## schachti

ok, ich habe das vielleicht etwas komisch ausgedrueckt, daher vielleicht etwas ausfuehrlicher:

Ich sitze an Rechner A, logge mich von dort auf dem Desktop ein. Auf dem Desktop arbeite ich dann mit grafischen Anwendungen (z. B. Firefox, OpenOffice etc.) ueber ssh, deswegen muss der sshd auf dem Desktop X-Forwarding unterstuetzen. Taete er es nicht, koennte ich von Rechner A aus ueber ssh keine grafischen Anwendungen auf dem Desktop nutzen.

Ausserdem logge ich mich vom Desktop aus auf Rechner B ein, der von Rechner A aus nicht erreichbar ist (also A --> Desktop --> B). Beim Aufbau dieser zweiten ssh-Verbindung kam es zu diesen seltsamen Wartezeiten. Die lassen sich beheben, wenn ich entweder in der /etc/ssh/sshd_config auf dem Desktop die Option X11Forwarding no setze (was nicht praktikabel ist, weil ich auf dem Desktop dann keine grafischen Anwendungen mehr starten kann, wenn ich mich per ssh von Rechner A aus dort angemeldet habe), oder indem ich beim ssh-Login vom Desktop aus auf Rechner B die Option -x angebe (denn auf Rechner B laeuft kein X).

Also:

```

schachti@RechnerA:~>ssh -X schachti@Desktop # hier brauche ich X-Forwarding

[...]

schachti@Desktop:~>ssh -x schachti@RechnerB # hier deaktiviere ich X-Forwarding

```

----------

## psyqil

Moin!  :Very Happy: 

Solltest Du dann nicht "X11Forwarding no" in /etc/ssh/sshd_config von Rechner B setzen? Auf den greifst Du schließlich zu vom Desktop aus...

Und hast Du denn -Y mal probiert? Nur so aus Interesse...

----------

## schachti

 *psyqil wrote:*   

> 
> 
> Solltest Du dann nicht "X11Forwarding no" in /etc/ssh/sshd_config von Rechner B setzen? Auf den greifst Du schließlich zu vom Desktop aus...
> 
> 

 

Ist auch gesetzt (default-Einstellung), lediglich auf dem Desktop ist X11Forwarding yes aktiviert.

 *psyqil wrote:*   

> 
> 
> Und hast Du denn -Y mal probiert? Nur so aus Interesse...
> 
> 

 

Ja, das aendert aber nichts.

----------

