Etch 4,0 & SSH > Putty

[AD-Admin]

Hi Leute,

ich hab ein minimales Problem mit Etch und SSH.
Und zwar folgendes: Login geht problemlos. (lokal ohne Probs)

Wenn ich von einem Windows Rechner mit Putty zu Etch connecte, wird direkt nach dem Login als username gefragt.

Dann trag ich z.b. root ein.
Und nachdem ich die Enter Taste drücke, daurt es ca. 5-10 sekunden bis ich das Passwort eingeben kann.
Sobald das Password dann eingegeben ist geht alles wunderbar schnell.

Es ist nur ein Delay nachdem man den Username eingegeben hat bis mans Password eingeben "darf"...

Habt ihr eine Idee woran das liegen könnte?
Bei Debian 3.1 ist dies nie vorgekommen.

Besten Dank.

[Six]

Die erste Frage wäre, wie bzw. über welche Art von Verbindung du zu deinem Server verbindest. Ist es ein lokaler Server oder z. B. das Gerät in deiner Signatur?

[AD-Admin]

Die erste Frage wäre, wie bzw. über welche Art von Verbindung du zu deinem Server verbindest. Ist es ein lokaler Server oder z. B. das Gerät in deiner Signatur?

Hi,

jo es ist ein Server im lokalen Lan.

z.b. 10.0.0.80 ; 10.0.0.90 sind ja mehrere.

Wie gesagt bei den 3.1 Servern gibt es dieses "Password" Problem nicht also diese verzögerung.

[Teddybear]

Moin

Also ich weiss nicht, wie man solch ein delay als "Problem" bezeichnen kann...
In der Regel gibt es immer ein delay bis zur Passwortabfrage, allein schon um es den netten script Kids etwas schwerer zu machen...

Aber es kann 2 Gründe geben, warum es zwischen 3.1 und 4.0 unterschiede gibt.
- Entweder Netzwerk mässig ein config problem
- Oder man hat das delay verlängert..

Greetz Sascha

[Six]

OK, ich denke da an ein paar Möglichkeiten:
1) Offensichtlich könnte der SSH-Host stark belastet sein und deine Anfrage spät bearbeiten. Gucke dir mal die Load-Werte an.
2) Der SSH-Client und der SSH-Host sind durch einen NAT/Proxy getrennt und dein SSH-Host benutzt das Ident-Verfahren. Dann aktiviere die Ident-Funktion auf deinem Client und stelle sicher, daß der NAT/Proxy diese Anfragen auch durchläßt. Wie das mit MS Windows geht, weiß ich allerdings nicht.
3) Die PAM Abfrage dauert lange. Melde dich auf dem SSH-Host an und betrachte die laufenden Prozesse (top sollte schon reichen) und melde dich von einem anderen SSH-Client nochmal an. Wenn die PAM-Abfrage lange dauert, dann kannst du kurzfristig mal die Passwortabfrage in der /etc/sshd.conf abschalten und es erneut versuchen. Geht es dann schneller, dann liegt ein noch genauer zu untersuchendes PAM Problem vor.
4) Unwahrscheinlich: Du versuchst dich per Namen auf dem SSH-Host anzumelden und reverse DNS Lookup klappt nicht bzw. nicht vollständig. Evtl. ist die neue (davon gehe ich mal aus) Maschine im Netz noch nicht gut genug bekannt oder der/die Router fahren garkein regelmäßiges Update. Das läßt sich leicht überprüfen, wenn du mal versuchst, dich direkt per IP auf dem SSH-Host anzumelden. Klappt das schneller, dann trage die IP/Namenskombination deines SSH-Clients einfach in die Hosts-Datei des SSH-Hosts ein, bei DHCP mußt du den DNS-Dienst aktualisieren.

Das sind die Dinge, die mir so in den Kopf kommen. Du kannst -- und solltest vielleicht -- auch noch mal die Netzverbindung an sich prüfen. Ich finde iperf bringt gute Ergebnisse, aber jeder hat ja so seine Lieblingstools

[Six]

Moin

Also ich weiss nicht, wie man solch ein delay als "Problem" bezeichnen kann...

Das ist z. B. ein Problem, wenn man CVS-Commits über einen SSH-Tunnel führt. Das ist durchaus gängige Praxis.

[AD-Admin]

OK, ich denke da an ein paar Möglichkeiten:
1) Offensichtlich könnte der SSH-Host stark belastet sein und deine Anfrage spät bearbeiten. Gucke dir mal die Load-Werte an.
2) Der SSH-Client und der SSH-Host sind durch einen NAT/Proxy getrennt und dein SSH-Host benutzt das Ident-Verfahren. Dann aktiviere die Ident-Funktion auf deinem Client und stelle sicher, daß der NAT/Proxy diese Anfragen auch durchläßt. Wie das mit MS Windows geht, weiß ich allerdings nicht.
3) Die PAM Abfrage dauert lange. Melde dich auf dem SSH-Host an und betrachte die laufenden Prozesse (top sollte schon reichen) und melde dich von einem anderen SSH-Client nochmal an. Wenn die PAM-Abfrage lange dauert, dann kannst du kurzfristig mal die Passwortabfrage in der /etc/sshd.conf abschalten und es erneut versuchen. Geht es dann schneller, dann liegt ein noch genauer zu untersuchendes PAM Problem vor.
4) Unwahrscheinlich: Du versuchst dich per Namen auf dem SSH-Host anzumelden und reverse DNS Lookup klappt nicht bzw. nicht vollständig. Evtl. ist die neue (davon gehe ich mal aus) Maschine im Netz noch nicht gut genug bekannt oder der/die Router fahren garkein regelmäßiges Update. Das läßt sich leicht überprüfen, wenn du mal versuchst, dich direkt per IP auf dem SSH-Host anzumelden. Klappt das schneller, dann trage die IP/Namenskombination deines SSH-Clients einfach in die Hosts-Datei des SSH-Hosts ein, bei DHCP mußt du den DNS-Dienst aktualisieren.

Das sind die Dinge, die mir so in den Kopf kommen. Du kannst -- und solltest vielleicht -- auch noch mal die Netzverbindung an sich prüfen. Ich finde iperf bringt gute Ergebnisse, aber jeder hat ja so seine Lieblingstools

Danke für die ausführliche Antwort Problem ist gelöst.

Und zwar folgendes:
Wir haben 2 DNS Server im netzwerk.
1x 10.0.0.77 und 1x 10.0.0.80

Die Etch Server hatten die 10.0.0.80 als primären DNS eingetragen und die 10.0.0.77 als sekundären DNS.

Allerdings war der 10.0.0.80 nicht immer verfügbar.
Und da er wohl versucht hat bei 10.0.0.80 eine reverse Abfrage zu machen hat er keine Antwort bekommen. Also hat ers bis zum Timeout probiert und danach 10.0.0.77 gefragt.

Und das war die Verzögerung.
Seit ich 10.0.0.77 als primären eingetragen habe, geht es gewohnt schnell.

Kann man in der Config von SSHD irgendwo diese DNS Prüfung abschalten?

Fazit
War kein fehler von Etch, sondern mein Fehler da die Etch Server die 10.0.0.80 als primären eingetragen hatten zu dem Zeitpunkt war der Server mit IP 10.0.0.80 jedoch offline gewesen.

[herrchen]

Kann man in der Config von SSHD irgendwo diese DNS Prüfung abschalten?

UseDNS
Specifies whether sshd should look up the remote host name and
check that the resolved host name for the remote IP address maps
back to the very same IP address. The default is ``yes''.

herrchen