Erster Sudo immer langsam


8

Das erste, was sudoich auf meinem Ubuntu 14.04-Server eingebe, ist immer langsam. Die Passwortabfrage wird sofort angezeigt, aber nachdem ich die Eingabetaste gedrückt habe, dauert es ungefähr 10-15 Sekunden, bis die Ausgabe gedruckt wird. Alle sudo-Befehle danach werden sofort ausgeführt.

Das Ausführen von so etwas sudo strace -S time -c sudo echo hizeigt in diesem Fall nichts Nützliches, da das sudo von sudo echo hibereits das zweite sudo ist und schnell ausgeführt wird. Wenn einige Zeit vergeht und ich das Passwort in einer laufenden Sitzung erneut eingeben muss, ist es wieder langsam.

Bei allen Lösungen, die ich gefunden habe, ging es darum, Ihren Hostnamen als Auflösung für 127.0.0.1 in die /etc/hostsDatei aufzunehmen, was ich ohne Erfolg getan habe. su rootwird sofort ausgeführt. Das einzige, woran ich mich erinnere, dass ich mich in den letzten Tagen geändert habe, ist die Netzmaske eines Subnetzes, das der Server weiterleitet und Samba, DNSNSILS und BIND9 installiert. Keiner dieser Prozesse wird jedoch ausgeführt, und das Problem besteht beim physischen Zugriff weiterhin auf SSH-Sitzungen sowie TMX-Sitzungen.

EDIT: Neuer Ansatz

Ich habe versucht zu laufen, sudo tcpdump -vvvi any > tcpdump.log während alle Netzwerkkarten getrennt waren. Das Protokoll zeigt viele der folgenden Elemente:

18:35:09.453399 IP (tos 0x0, ttl 64, id 49112, offset 0, flags [DF], proto UDP (17), length 76)
    localhost.38498 > localhost.domain: [bad udp cksum 0xfe4b -> 0x1050!] 58546+ SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. (48)
18:35:09.457412 IP (tos 0x0, ttl 64, id 49113, offset 0, flags [none], proto UDP (17), length 76)
    localhost.domain > localhost.38498: [bad udp cksum 0xfe4b -> 0x8fcd!] 58546 ServFail q: SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. 0/0/0 (48)

Gleiche Einträge werden mit tcp instad von udp angezeigt. Ich habe den Domainnamen unserer Universität durch OURLOCALDOMAIN ersetzt.

Jetzt denke ich, dass Kerberos vielleicht etwas damit zu tun hat, aber ich habe die /etc/krb5.conf gelöscht und neu gestartet, immer noch keine Änderung. Es scheint mir, dass der Server versucht, sich auf einem zentralen Kerberos-Server aus unserem Universitätsnetzwerk zu validieren. Ich weiß, dass diese IP einige Jahre zuvor auf einem Server registriert war, auf dem Samba für unsere Abteilung ausgeführt wurde. Könnte es eine Verbindung geben? Ich habe meinen Hostnamen in den damals verwendeten geändert, ohne das Sudo-Verhalten zu ändern. Lmwangi schlägt etwas über PAM vor, über das ich wenig weiß, daher weiß ich nicht, wie ich das angehen soll. Ich erinnerte mich auch, dass ich bei der Installation von Samba von Heimdal Kerberos zu MIT Kerberos gewechselt war, weil ich während der Samba-Installation Probleme hatte. Ich werde in den nächsten Tagen auch die Ideen aus den Kommentaren ausprobieren, aber ich werde ein paar Tage unterwegs sein, daher kann es einige Zeit dauern.

EDIT 2: Gelöst

Es gab einen alten DNS-Sucheintrag in der /etc/network/interfaces, der alles durcheinander brachte. Ich fühle mich sehr dumm. Alles funktioniert jetzt.


1
Wenn straceSie das Set-UID-Bit vorübergehend aktivieren , können Sie es ohne das erste ausführen sudo. Es könnte auch helfen , die zu verwenden , -o <file>die Ausgabe in eine Datei zur Analyse Option zu speichern.
GarethTheRed

1
Das ist der eine. Folgen Sie sudo -kdem Befehl, um Ihren zwischengespeicherten Berechtigungsnachweis zu entfernen. Ich fand strace -Tro sudo.log sudo echo hies nützlich, da die letzte Spalte die Zeit in jedem Anruf anzeigt. grepfür unameund socketals Vorspeise.
GarethTheRed

1
Die 5,005153 Sekunden sind von der -rOption (die möglicherweise entfernt werden sollte). Suchen Sie zunächst nach den langen Anrufen aus der -TOption - sie sind diejenigen innerhalb der <und >- 0,000097 Sekunden in Ihrem Fall.
GarethTheRed

1
Haben Sie ps, top und alle Systemprotokolldateien überprüft, falls etwas anderes passiert, um die Langsamkeit zu verursachen?
Mdpc

1
Können Sie Ihre Pam-Konfiguration veröffentlichen? straceSie werden irgendwann dorthin gelangen, aber dies ist wahrscheinlich ein Konfigurationsproblem auf höherer Ebene. Die meisten langen Pausen während der Authentifizierung sind darauf zurückzuführen, dass der Zugriff auf Remoteserver fehlschlägt und auf eine Zeitüberschreitung gewartet werden muss. Möglicherweise hat die Subnetzänderung den Authentifizierungsserver in ein anderes Subnetz als dieses versetzt. sudoSpeichert vorübergehend eine Aufzeichnung der erfolgreichen Authentifizierung darunter, /varsodass nachfolgende Aufrufe wahrscheinlich sofort ausgeführt werden.
Bratchley

Antworten:


2

Ich würde vermuten, dass Ihre Box versucht, einen externen Authentifizierungsdienst (denken Sie an NIS / LDAP) über PAM zu kontaktieren ...

Wenn ich PAM richtig verstehe, können Sie die PAM-Suche in Ihren Strace-Anrufen nicht sehen. Ich würde vorschlagen, dass Sie tshark / tcpdump ausführen und prüfen, ob Sie bestimmten Netzwerkverkehr mit Ihren Sudo-Versuchen korrelieren können. Verdächtige hier wären DNS-Lookups & | LDAP-Aufrufe.

tcpdump -i eth0 -w network.pcap -s0 -Av

Wenn Sie herausfinden, was die Suchvorgänge verursacht, finden Sie das entsprechende PAM-Modul heraus, um das Problem zu bearbeiten und zu beheben. Wenn es sich um eine DNS-Suche handelt, fügen Sie alternativ einfach einen / etc / hosts-Eintrag hinzu, um den Namen zu fälschen und zu localhost umzuleiten. Dies macht Ihr sudo schnell, da die Suche schnell ist und zum localhost umleitet und die Netzwerktransaktion schnell fehlschlägt, da localhost nicht abgehört wird ...


Nun scheint dies in eine gute Richtung zu gehen. Ich habe viele Aufrufe von "bad udp cksum" und "bad tcp cksum" in meinem Protokoll. Es ist zu lang, um einen Kommentar abzugeben, daher werde ich das OP in einer Sekunde aktualisieren.
Zerweck
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.