it-swarm.com.de

Sudo SU kann nicht mehr verwendet werden.

Ich habe einen Stammserver, bei dem ich die Anmeldung über den Benutzer root deaktiviert und einen anderen Benutzer erstellt habe, der sich in der sudoer-Liste befindet. Wenn ich also auf dem Server arbeiten möchte, mache ich:

ssh [email protected]_ADDRESS

Auf dem Server:

Sudo su

gib mein Passwort ein, um Root-Rechte zu erhalten. Dies funktionierte nun seit 6 Monaten gut. Heute erhalte ich diese Nachricht, wenn ich Sudo su:

Sudo: no tty present and no askpass program specified

Was ist der Hack? Was bedeutet dieser Fehler und warum bekomme ich ihn? Ohne Root-Rechte kann ich auf dem Server nicht so viel tun. Irgendeine Idee, wie man das beheben kann?

7
Artjom Zabelin

Sudo versucht, /dev/tty für Lese- und Schreibzugriff zu öffnen, und druckt diesen Fehler, falls er fehlschlägt. Sie haben in Kommentaren angegeben, dass/dev/tty auf Ihrem System fehlt.

Sudo hat eine Option -S, um das Passwort von der Standardeingabe anstelle von/dev/tty zu lesen. Sie sollten Sudo -S ausführen können, um root zu werden.

In Bezug auf die Wiederherstellung von/dev/tty ist es möglicherweise ausreichend, den Server neu zu starten. Das System erstellt möglicherweise während des Startvorgangs alle Geräte in/dev neu. Um ein Gerät zu erstellen, verwenden Sie alternativ den Befehl mknod. Sie müssen jedoch die richtigen Haupt- und Nebennummern für das tty-Gerät kennen. Auf einem Ubuntu-System, das ich zur Verfügung habe, sehe ich diese Einträge in/dev:

crw------- 1 root root      5,   1 Apr 16 18:36 console
crw-rw-rw- 1 root tty       5,   2 Sep 24 15:35 ptmx
crw-rw-rw- 1 root tty       5,   0 Sep 24 14:25 tty

In diesem Fall ist die Hauptzahl 5 und die Nebennummer 0./dev/console und/dev/ptmx haben dieselbe Hauptnummer. Ich würde also/dev/console oder/dev/ptmx nach der richtigen Hauptnummer suchen und dann ausführen:

mknod /dev/tty c major 0

dabei ist "major" die richtige Hauptzahl.

Stellen Sie nach dem Erstellen von/dev/tty sicher, dass die Berechtigungen korrekt sind:

chmod 666 /dev/tty
17
Kenster

Es schlägt fehl, da Sudo versucht, die Aufforderung für das root-Passwort einzugeben, und es ist keine Pseudo-Identität zugeordnet.

Sie müssen sich entweder als root anmelden oder die folgenden Regeln in Ihrem /etc/sudoers (oder: Sudo visudo) einrichten:

# Members of the admin group may gain root privileges.
%admin  ALL=(ALL) NOPASSWD:ALL

Stellen Sie dann sicher, dass Ihr Benutzer zur admin-Gruppe (oder wheel) gehört.

Idealerweise (sicherer) wäre es, Root-Berechtigungen nur auf bestimmte Befehle zu beschränken, die als %admin ALL=(ALL) NOPASSWD:/path/to/program angegeben werden können.

6
kenorb

Zu prüfen ist, ob das Betriebssystem der Meinung ist, dass die verschiedenen Prozesse "tty" haben. Wenn Sie immer noch Probleme haben, lohnt es sich wahrscheinlich, dies sowohl in der Shell, in der Sie ssh ausführen, als auch in der Shell, in der Sie Sudo ausführen. Der einfachste Weg, dies zu überprüfen, ist der Befehl "tty". Wenn er "nicht tty" zurückgibt, verfügt Shell nicht über ein "steuerndes tty" und kann/dev/tty nicht öffnen, selbst wenn es im Dateisystem vorhanden ist.

Verschiedene Umstände können dazu führen, dass eine Shell nicht mit einem Steuerelement ausgeführt wurde, und einige von ihnen geben keine sichtbare Warnung aus. ZB bin ich kürzlich in High Sierra mit Emacs Shell-Fenstern in ein Problem geraten ( Pty kann nicht unter Mac OS High Sierra geöffnet werden ) - High Sierra verwendet einen anderen Mechanismus für die Zuweisung von pty's als frühere Mac OS X-Versionen Code wird nicht neu konfiguriert, es kann keine pty zugewiesen werden.

0
user2864482