Lange Wartezeit beim Login

Wenn ich mich auf meinem Server anmelde, erhalte ich Folgendes:

No mail.
Last login: Fri Nov  5 14:22:45 2010...

dann muss ich 5 sek warten und ist dann fertig ...

wolfy@ubuntu-server:~$

Ist diese Wartezeit normal oder sollte ich etwas tun, um dies zu "reparieren"?

Dies ist normalerweise das Ergebnis der pam_motdNeuerstellung der /etc/motdDatei. Sie können die einzelnen Skripte einchecken, um festzustellen /etc/update-motd.d, ob etwas besonders langsam ist.

Ich habe die gleichen Probleme mit 10.04 (LTS).

Wenn ich mein ssh mit starte -vvv, stirbt es an:

debug1: Entering interactive session.

Diese Antwort erweitern.

Ich konnte den Server remote neu starten und die DEBUG-Protokollierung aktivieren. Nutzen Sie diese Gelegenheit auch, um eingeloggt zu bleiben und andere Anmeldeversuche zu beobachten. Folgendes passiert. Der Client stellt eine Verbindung her und ist autorisiert und hängt an der obigen Nachricht.

Auf dem Server zeigt die Prozessliste Folgendes:

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

Ich kann problemlos ausführen, /usr/bin/python /usr/bin/landscape-sysinfowährend ich angemeldet bin, aber aus irgendeinem Grund kann ich nicht herausfinden, warum der Anmeldevorgang dadurch blockiert wird. Wenn ich den Vorgang beende, wird die Anmeldung an der Eingabeaufforderung fortgesetzt und ist erfolgreich .

Dies scheint kein ssh (d) -Problem zu sein, sondern eher eine Beziehung zu update-motdund Landschaft. Ich habe das update-motdPaket deinstalliert , aber es scheint, als ob das /etc/update-motdVerzeichnis bestehen bleibt und die Skripte immer noch ausgeführt werden - wodurch der Prozess hängen bleibt.

Weiteres Debuggen:

Es stellt sich heraus, dass das /etc/update-motd.d/Verzeichnis nicht wirklich zum Paket gehört update-motd, sondern durch die Pam-Authentifizierung über sshd ausgelöst zu werden scheint.

Ich scheine es genagelt zu haben!

Deaktiviert pam_motd in den folgenden Dateien:

• /etc/pam.d/sshd
• /etc/pam.d/login

Einer noch:

apt-get purge landscape-client landscape-common

Diese scheinen in gewissem Maße zu helfen. Es entfernt jedoch nur das fehlerhafte Skript in /etc/update-motd.d/und löscht weder alle Skripte in diesem Verzeichnis noch wird es entfernt pam_motd.

Im Allgemeinen habe ich keine Möglichkeit gefunden, die Funktion pam_motdvollständig zu deaktivieren, da sie den Anmeldevorgang anscheinend bis zu einem gewissen Grad verlangsamt. Es blockiert nicht wie das Skript landscape-common, ist aber langsamer.

Fehlerbericht zu diesem Problem:

• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/805423

Problemumgehungen von dort:

Sie haben Recht, dass die Fähigkeit, sich einzuloggen, wichtiger ist als die Vorlage eines Motivs. Wenn dieses Verhalten ein Problem für Sie ist, können Sie es auf verschiedene Arten deaktivieren:

• Kommentieren Sie die Zeile 'pam_motd' aus, /etc/pam.d/sshdwenn Sie kein motd anzeigen möchten.
• Löschen Sie den Inhalt des /etc/update-motd.dVerzeichnisses.
• chmod -x die Skripte /etc/update-motd.d, die Sie nicht ausführen möchten.

Ich habe endlich eine Lösung gefunden:

1. sudo apt-get remove landscape-client landscape-common
2. Kommentarzeile session optional pam_motd.so in /etc/pam.d/loginund/etc/pam.d/sshd

Jetzt ist der Login SOFORT!

Ihrer Beschreibung nach klingt es eher nach einem Netzwerkproblem. Diagnostizieren:

• Führen Sie ssh mit dem Parameter -v aus, um ausführlich zu sein.
• Versuchen Sie, einen Ping an den SSH-Server auszuführen, mit dem Sie eine Verbindung herstellen, und prüfen Sie, ob dieser gleichzeitig hängt.
• Versuchen Sie es mit einer anderen Art der Übertragung auf denselben Server. Beispiel: Wget mit dem Parameter --limit-rate, um eine Datei über HTTP abzurufen, und es dauert lange genug, bis das "Hängen" -Verhalten ausgelöst wird.
• Sehen Sie, ob es nur im Leerlauf hängt oder ob Sie gerade etwas tun. Wenn es im Leerlauf hängt, werden Sie wahrscheinlich von der -v-Diagnose darauf hingewiesen. In diesem Fall kann der Hinweis zur Verwendung von keepalive hilfreich sein (ssh -o "TCPKeepAlive yes").

Wenn Sie mit Windows und PuTTY eine Verbindung herstellen können, ist dies wahrscheinlich kein Problem auf der Serverseite.

Wenn PermitEmptyPasswordund UsePAMbeide aktiviert sind, versucht der OpenSSH-Server immer, sich mit einem Nullkennwort zu authentifizieren. Dies ist ein Zeichen dafür, dass für das betreffende Konto keine Authentifizierung erforderlich ist. Dies geschieht in beiden Protokollen, sobald der Authentifizierungsprozess beginnt, und nicht als Antwort auf eine "echte" Authentifizierungsanforderung vom Client. OpenSSH lässt einen solchen Zugriff nur zu, wenn das Flag sshd_config PermitEmptyPasswordgesetzt ist. Leider führt der Code, wie er geschrieben ist, in jedem Fall den Passworttest durch und zeigt damit PAM als Fehler an.

Also: deaktivieren Sie PermitEmptyPasswordoder UsePAM, aber denken Sie daran: Ohne PAM können Sie sich nicht ohne Schlüssel anmelden.

Referenz: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

Ich denke, wenn Sie sich anmelden, führt Ubuntu eine oder mehrere der folgenden Dateien aus:

/etc/bash.bashrc
~/.bash_profile
~/.bashrc

Sie könnten sehen, was in ihnen ist und vielleicht sogar versuchen, sie auszuführen, um zu sehen, was so lange dauert.

In meiner begrenzten Erfahrung, wenn Kitt funktioniert, aber Linux, in diesem Fall Ubuntu, nicht, ist es in der Regel am Leben zu halten. Netzwerk- oder Serverprobleme wirken sich auf beide Clientbetriebssysteme aus.

Sie können die obige Keep-Alive-Option in der Befehlszeile verwenden, die Eingabe ist jedoch etwas mühsam.

Ein paar Konfigurationsdateien lassen sich einfacher bearbeiten.

Wenn Sie haben root accessund es automatisch für alle Benutzer aktivieren möchten, bearbeiten Sie es /etc/ssh/ssh_configund fügen Sie es hinzu

KeepAlive yes
ServerAliveInterval 120

Wenn Sie keinen Root-Zugriff haben oder diesen für einen einzelnen Benutzer aktivieren möchten, bearbeiten ~/.ssh/configund fügen Sie dieselben zwei Zeilen hinzu.

Überprüfen Sie Ihre Systemprotokolle unter / var / log. Möglicherweise finden Sie eine Meldung mit dem entsprechenden Fehler / Timeout.

Wenn Sie auch eine Zeit haben, warten Sie vorher

Bearbeiten /etc/sshd_config

und setzen (oder hinzufügen)

UseDNS no

Oder fügen Sie Ihre IP-Adresse hinzu, /etc/hostswenn es sich um eine statische lokale handelt

Möglicherweise möchten Sie versuchen, die ausgeführten Prozesse zu überwachen, während Sie sich über eine bereits angemeldete Verbindung (oder eine andere Konsole) beim Server anmelden. Es besteht die Möglichkeit zu erkennen, welche Prozesse zu diesem Zeitpunkt am aktivsten sind oder die meiste CPU verbrauchen.

Nachfolgend finden Sie eine mögliche Methode:

1. Versuchen Sie, sich an einer anderen Konsole anzumelden.
2. Lauf topdorthin, um zu sehen, was passiert.
3. Melden Sie sich an der ersten Konsole an.

Bitte beachten Sie, dass Sie nichts falsches erkennen, wenn die Verzögerung nicht durch eine CPU-intensive Berechnung verursacht wird. In diesem Fall ist das Problem möglicherweise E / A-gebunden (Warten auf Lese- / Schreibzugriff oder Netzwerkantwort).