Frage Ist es in Ordnung, passwortloses `sudo` auf einem Cloud-Server einzurichten?


Ich mag die Idee, über Schlüssel auf Server zuzugreifen, damit ich nicht jedes Mal mein Passwort eingeben muss ssh in eine Box, sperre ich sogar meine Benutzer (nicht root) Passwort (passwd -l username) so ist es unmöglich um sich ohne Schlüssel anzumelden.

Aber das alles bricht, wenn ich ein Passwort eingeben muss sudo Befehle. Also bin ich versucht, mich zu richten passwortlos sudo um die passwortlose Anmeldung zu ermöglichen.

Aber ich habe immer das Gefühl, dass es auf eine unerwartete Art auf mich zurückfallen könnte, es scheint irgendwie unsicher zu sein. Gibt es irgendwelche Vorbehalte bei solchen Einstellungen? Würden Sie dies für ein Benutzerkonto auf einem Server empfehlen / nicht empfehlen?

Erläuterungen

  1. Ich spreche von der Verwendung von sudo in einer interaktiven Benutzersitzung hier, nicht für Dienste oder Verwaltungsskripte
  2. Ich spreche über die Verwendung eines Cloud-Servers (ich habe also keinen physischen lokalen Zugriff auf einen Computer und kann mich nur remote anmelden)
  3. ich weiß das sudo hat eine Zeitüberschreitung, während der ich mein Passwort nicht erneut eingeben muss. Aber bei meinem Konzert geht es nicht wirklich darum, die zusätzliche Zeit zu verschwenden, um ein Passwort einzugeben. Meine Idee war jedoch, dass ich mich überhaupt nicht mit einem Passwort befassen musste, denn ich nehme an, dass:
    • Wenn ich es mir überhaupt merken muss, ist es sehr wahrscheinlich zu kurz, um sicher oder wiederverwendet zu werden
    • Wenn ich ein langes und eindeutiges Passwort für mein Remote-Konto erstelle, muss ich es irgendwo speichern (ein lokales Passwort-Manager-Programm oder ein Cloud-Service) und es jedes Mal holen, wenn ich es verwenden möchte sudo. Ich hoffte, ich könnte das vermeiden.

Mit dieser Frage wollte ich die Risiken, Vorbehalte und Kompromisse einer möglichen Konfiguration besser verstehen als die anderen.

Folge 1

Alle Antworten sagen, dass passwortlos sudo ist unsicher, da es eine "einfache" Eskalation von Privilegien erlaubt, wenn mein persönliches Benutzerkonto kompromittiert wird. Ich verstehe das. Wenn ich jedoch ein Passwort benutze, gehen wir alle klassischen Risiken mit Passwörtern ein (zu kurze oder gemeinsame Zeichenfolge, wiederholt über verschiedene Dienste usw.). Aber ich denke, wenn ich die Passwortauthentifizierung in deaktivieren /etc/ssh/sshd_config Damit du noch einen Schlüssel zum Einloggen hast, kann ich einfach ein einfacheres Passwort verwenden sudo das ist einfacher einzugeben? Ist das eine gültige Strategie?

Folge 2

Wenn ich auch einen Schlüssel habe, um mich einzuloggen root via ssh, wenn jemand Zugang zu meinem Computer bekommt und meine Schlüssel stiehlt (sie sind immer noch durch das Schlüsselwort des Betriebssystems geschützt!), können sie auch einen direkten Zugriff auf die root unter Umgehung der sudo Pfad. Was sollte die Richtlinie für den Zugriff auf die sein? root Konto dann?


56
2018-03-09 21:40


Ursprung


Würde es überhaupt nicht empfehlen, da es oft Möglichkeiten gibt, eine Shell als Benutzer zu erhalten (da alle Dienste einer Sicherheitsverletzung unterliegen, aber normalerweise als Benutzer ausgeführt werden, um vollen Zugriff auf das System zu vermeiden), aber ein Passwort zum Anmelden haben root verhindert, dass Unbefugte Root-Zugriff erhalten. Wenn keine vorhanden ist, hat jeder, der Zugriff auf Ihr Benutzerkonto erhält, vollen Zugriff auf den Server. Das Einstellen eines Passworts ist vielleicht nicht viel, aber es hilft. - piernov
Bitte beachten Sie meine Follow-up Fragen - Dmitry Pashkevich
sudo sollte niemals passwortlos sein. root sollte von Remote-Login über SSH deaktiviert werden, SSH-Port sollte nicht standardmäßig sein (um die Dumb-Bots zu entfernen), und jedes Konto, das sudo benötigt, sollte entweder auf die sudo-Mächte beschränkt sein, die sie benötigen (einen Dienst neu starten) nur, usw.) und haben auch sehr starke Passwörter. - SnakeDoc
@SnakeDoc Danke, das ist eine Art Antwort, die ich erwartet habe. Möchten Sie eine detaillierte Antwort schreiben? Ich freue mich zu lernen! - Dmitry Pashkevich
@EEEAA es ist eigentlich ziemlich einfach in Linux. Die einzigen Accounts, die in sudo passwortlos sein dürfen, sind Systemaccounts, bei denen man sich nicht anmelden kann und die daher nicht auf dieses Konto zugreifen und diese Berechtigungen gegen Sie verwenden können. Legen Sie eine falsche Shell für das Konto fest /etc/passwd wie nologin, setze kein passwort und setze passwordless in visudo. Wenn Sie dies tun, sollten Sie auch sicherstellen, dass die visudo-Einstellung nur für das bestimmt ist, was der Systemaccount absolut benötigt, dh, sperren Sie ihn auf die einzigen Befehle, die er jemals ausführen sollte. - SnakeDoc


Antworten:


Ich mag die Idee, über Schlüssel auf Server zuzugreifen, so dass ich nicht muss   Gib jedesmal mein Passwort ein, wenn ich in eine Box sshch, ich sperre sogar meinen Benutzer ein   (nicht root) Passwort (passwd -l Benutzername), so dass es unmöglich ist, sich einzuloggen   ohne Schlüssel ... Würdest du empfehlen / nicht empfehlen, dies für einen zu tun   Benutzerkonto auf einem Server?

Sie gehen daran, passwortbasierte Logins auf die falsche Art zu deaktivieren. Anstatt das Konto eines Benutzers zu sperren, legen Sie fest PasswordAuthentication no in deiner /etc/ssh/sshd_config.

Mit diesem Set ist die Passwortauthentifizierung für ssh deaktiviert, aber Sie können weiterhin ein Passwort für sudo verwenden.

Das nur Zeit empfehle ich Einstellung NOPASSWD In Sudo ist für Dienstkonten, wo Prozesse in der Lage sein müssen, Befehle über Sudo programmgesteuert auszuführen. Stellen Sie unter diesen Umständen sicher, dass Sie nur die Spezifisch Befehle, die das Konto ausführen muss. Für interaktive Konten sollten Sie immer Lassen Sie Passwörter aktiviert.

Antworten auf Ihre Follow-up-Fragen:

Aber ich denke, wenn ich die Passwortauthentifizierung in deaktivieren   / etc / ssh / sshd_config, damit Sie immer noch einen Schlüssel zum Einloggen haben müssen, I   sch sch sch sch sch sch 100 sch sch sch sch 100 100 sch sch sch sch 100 sch sch sch sch 100 sch sch sch sch 100 sch sch sch sch sch 100 sch sch sch sch 100 sch sch sch sch sch sch 100 sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch 100 sch sch sch sch sch sch sch sch sch sch sch sch dieser Ist   das eine gültige Strategie?

Ja das ist richtig. 100 100 sch sch sch sch sch sch sch sch sch 100 sch 100 sch 100 sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch 100 sch 100 sch sch sch sch sch sch sch 100 sch sch sch sch sch sch 100 zwischen sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch zwischen sch sch sch sch sch dieser ~ 8 Zeichen, zufällig generiert ist ausreichend.

Wenn ich auch einen Schlüssel habe um mich als root über ssh einzuloggen, wenn jemand kommt   Zugang zu meinem Computer und stehlen meine Schlüssel (sie sind immer noch geschützt durch   Sch 100 100 sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch 100 sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch dieser   an den root-Account unter Umgehung des sudo-Pfades.

Root-Zugriff über ssh sollte deaktiviert werden. Zeitraum. einstellen PermitRootLogin no in deiner sshd_config.

Wie lautet die Richtlinie für den Zugriff auf das root-Konto?

Sie sollten immer Zugriff auf die Konsole Ihres Servers erhalten. Mehrere VPS-Anbieter bieten dies ebenso wie Anbieter von dedizierter Hardware. Wenn Ihr Provider keinen echten Konsolenzugriff gewährt (z. B. EC2), können Sie den Zugriff in der Regel immer noch mithilfe eines Prozesses wiederherstellen, wie er in dem Beispiel beschrieben ist diese Antwort.


46
2018-03-09 21:48



+1 sollte Passwörter hinterlassen ... - Chris S
+1 das sudo Passwort ist nicht Ja wirklich dort für secutiry (soweit ich sehen kann) aber eher als Idiotscheck. Nicht dort zu sein, konnte ungeahnte Havok verursachen. - Boris the Spider
Wenn Sie Ihren Schlüssel verlieren, sind Sie fertig, es sei denn, Sie haben eine Hintertür, aber auch einen Angreifer. Der einzige Weg, einen verlorenen Schlüssel zu reparieren, wäre, wenn er richtig gemacht würde, physisch am eigentlichen Terminal zu sitzen. Wenn Sie die Art von Schutz benötigen, die ssh-Schlüssel bieten, sollten Sie sich der Gefahren bewusst sein und einfach ... verlieren Sie einfach nicht Ihre Schlüssel. - SnakeDoc
Ein Kommentar zu Ihrem letzten Paragraphen, und in Bezug auf den Verlust des Zugriffs für alle VPS ... einige VPS-Anbieter werden Ihnen helfen, wenn Sie ausgesperrt werden. Ich hatte eine VM in den Einzelbenutzermodus booten und einige Dinge für mich tun, wenn ich mich selbst aussperrte (es passiert ... schlechte Firewall-Regel lol). Abhängig von Ihrem Host, können sie Ihnen Gebühren für den Dienst, sie sind Schließlich widmen wir Ihnen besondere Aufmerksamkeit und einige Backups / Snapshots für einen geringen Preis oder manchmal auch kostenlos, was sich für den Fall einer großen, möglicherweise störenden Änderung lohnen kann. - SnakeDoc
@DmitryPashkevich - in Bezug PasswordAuthentication Auswirkungen auf alle Benutzer, können Sie immer verwenden Match Abschnitte in sshd_config, um sie für bestimmte Benutzer oder Gruppen wieder zu aktivieren. - Matt Thomason


Ich schränke den Gebrauch von allgemein ein NOPASSWORD zu Befehlen, die von einem automatisierten Prozess ausgeführt werden. Es ist vorzuziehen, für diese Befehle ein Dienstkonto zu haben und die Verwendung von sudo auf die erforderlichen Befehle einzuschränken.

Erlauben NOPASSWORD sch 100 sch 100 sch 100 sch 100 sch 100 sch 100 sch 100 sch 100 sch 100 100 100 sch 100 sch dieser sch 100 sch 100 100 sch 100 100 sch 100 100 sch sch sch sch 100 sch sch sch sch 100 sch 100 sch 100 sch 100 sch 100 sch 100 sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch sch 100 sch dieser Dies könnte auf eine Kompromittierung Ihrer Anmeldeinformationen zurückzuführen sein, könnte aber so einfach sein wie jemand, der an Ihrem Schreibtisch sitzt, wenn Sie für eine Sekunde weggehen.

Ich finde, dass ich mein Passwort nicht oft eingeben muss. Sobald Sie Ihr Passwort eingegeben haben, können Sie mehrere Befehle ausführen, wenn Sie nicht zu lange warten. Die Zeitüberschreitung ist konfigurierbar.


10
2018-03-10 00:18





Ich würde das nur in zwei Fällen verwenden:

  • Wann ist es absolut erforderlich für ein automatisiertes Skript, das als ein bestimmter Benutzer ausgeführt wird
  • Für bestimmte Admin-Aufgaben (Nur-Lese-Admin-Aufgaben, nicht diejenigen, die Maßnahmen ergreifen, um das System zu ändern) und dann nur für bestimmte Benutzer natürlich

Standardmäßig am meisten sudo Konfigurationen werden Sie in der gleichen Sitzung eine Weile nicht mehr fragen (wenn Sie eine neue Shell öffnen, die keinen Effekt hat). Sie können dieses Verhalten mit dem timestamp_timeoutRahmen.

Passwortlos sudo ist nicht annähernd so gefährlich wie Passphrase-less ssh Schlüssel, da ein entfernter Angreifer Ihre Anmeldeinformationen benötigt, um an erster Stelle zu sein, aber wenn sie Ihren privaten Schlüssel irgendwie kompromittiert haben (oder wenn sie physisch in Ihrer Nähe sind und Sie sich eingeloggt und während Ihrer Abwesenheit entsperrt haben) von der Maschine) dann ist die Passwort-Anfrage eine wertvolle zusätzliche Verteidigung zwischen ihnen und privilegierten Zugriff.

Zu Folge 2:

Wenn ich auch einen Schlüssel habe, um mich als root über ssh anzumelden

Dies ist auch am besten zu vermeiden, genau aus dem Grund, den Sie beschreiben. Wenn eine Remote-Verbindung einen privilegierten Zugriff haben soll, muss sie sich über einen Dienstaccount anmelden und nur so viel Kontrolle geben, dass sie ihre Arbeit über sudo erledigen kann. Dies ist natürlich mehr zu konfigurieren, so viele stören nicht (was zu Ihren Gunsten funktioniert, da es viel weniger hängenden Früchten als Sie für Angreifer gibt, um dort Zeit zu verbringen!), So kommt es auf die uralter Kompromiss zwischen Sicherheit und Komfort (Profi-Tipp: Sicherheit holen!).


8
2018-03-10 09:47



Danke, dass Sie meine Follow-up # 2 angesprochen haben. Ich bin aber immer noch verwirrt: Ich versuche, mich nicht einzuloggen root direkt, aber ich brauche eine Möglichkeit, auf das Konto zuzugreifen, richtig? Wie mache ich es dann? Mit einem Passwort, nicht ssh-Schlüssel? Aber sind Schlüssel nicht besser als Passwörter? - Dmitry Pashkevich
Sie können sich immer lokal als root anmelden, aber es wird empfohlen, dass direkte Logins von root von entfernten Hosts (via ssh oder ähnlichem) vollständig deaktiviert werden. Wenn Sie einen Account haben, der über sudo root werden kann (natürlich mit Passwort), verlieren Sie nie den Zugriff auf das Konto. - David Spillett


Sie können das Beste aus beiden Welten haben: SSH-Authentifizierung sowohl für Login als auch für Sudo. Wenn Sie das integrieren pam_ssh_agent_auth Modul können Sie SSH-Schlüssel verwenden, um sich zu authentifizieren, ohne ein Kennwort zu geben, wenn Sie sudo.

Ich verwende das seit mehr als fünf Jahren in der Produktion.

Installieren Sie das PAM-Modul, und fügen Sie dann eine Zeile hinzu, um es zu konfigurieren /etc/pam.d/sudo oder das Äquivalent Ihres Systems:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

Wenn Sie dies tun, sollten Sie Ihre Schlüssel auf Ihrem Computer mit einer Passphrase schützen. Auf diese Weise müsste jemand in deinen Computer eindringen und die Schlüssel stehlen, um hineinzukommen. Sie könnten das tun, indem sie sie aus dem Speicher ziehen, wenn sie Zugriff auf dein Konto haben, indem sie deine Passphrase knacken oder deine Passphrase stehlen ein Keylogger oder eine Schulter, während du es eintippst (schau hinter dich!).

Sie können den gleichen SSH-Schlüssel verwenden wie beim Anmelden, oder Sie können einen separaten Schlüssel einrichten, den Sie nur Ihrem Agenten hinzufügen, wenn Sie sudo ausführen. Wenn Sie besonders vorsichtig sein möchten, können Sie eine separate authorized_keys-Datei mit einem separaten SSH-Schlüssel verwalten, den Sie nur dann Ihrem Agenten hinzufügen, wenn Sie sudo ausführen müssen:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

7
2018-03-12 12:34



Wow, das klingt großartig! Also erzeuge ich einen separaten Schlüssel zum Ausführen sudo Befehle oder verwende ich den gleichen, der für die SSH-Authentifizierung verwendet wurde? - Dmitry Pashkevich
Das ist großartig. Ich würde Sie mehrmals aufrüsten, wenn ich könnte. - nyuszika7h
Sie können den gleichen Schlüssel wie für die normale SSH-Authentifizierung verwenden, oder für zusätzliche Sicherheit können Sie vorübergehend einen Schlüssel hinzufügen, den Sie für Ihren SSH-Authentifizierungsagenten verwenden. Dies würde erfordern, dass Sie eine andere Datei als angeben ~/.ssh/authorized_keys, Sie könnten eine andere Datei verwalten, ~/.ssh/authorized_keys_sudo zum Beispiel, oder /etc/ssh/authorized_keys_sudo. - obscurerichard


Da du gefragt hast, hier ist mein allgemeiner Ratschlag, wie man das anspricht sudo Problem.

Sudo wurde nicht entwickelt, um mehr Sicherheit zu bieten (obwohl es in gewisser Hinsicht möglich ist) ... sondern bietet einen guten Überblick darüber, wer was auf Ihrem System mit welchen Privilegien macht.

Ein richtig eingerichtetes Sudo wird das nicht verwenden ALL=(ALL) ALL Einstellung, sondern eher etwas begrenzter auf was auch immer es speziell ist, dass der Benutzer braucht. Wenn Sie zum Beispiel einen Benutzer benötigen, um sich anzumelden und einen festgefahrenen Dienst neu zu starten, müssen Sie wahrscheinlich keine neue Software installieren oder Ihren Server herunterfahren, Firewall-Regeln ändern usw.

Es ist manchmal üblich, dass Leute sudo verwenden, um sich selbst zum root-Konto zu erheben, d. sudo su -. Sobald Sie das tun, hören Sie auf zu sehen, wer was tut, aus dem root-Konto (root kann mehrere Male gleichzeitig angemeldet sein). Also manchmal wollen Leute das deaktivieren sudo su -Befehl auch. Aber aus praktischen Gründen, wenn Sie ein vollständig root-privilegierten Konto für die Verwaltung benötigen, zumindest jemanden mit dem Problem sudo su - Befehl würde protokollieren, wer wann auf root erhöht wurde.

Wie sichere ich meine Boxen:

Ändern Sie den SSH-Port in einen anderen als den Standardport. Das ist, um zu vermeiden, dass die Bots, die nach Port-Nummern suchen, wegspringen, bis sie hinein kommen (oder nicht).

Root-Anmeldung über SSH nicht zulassen über die AllowRootLogin no Einstellung in Ihrer sshd_config. Dadurch wird verhindert, dass jemand brutal in Ihr root-Konto eindringt. Es ist in der Regel eine gute Methode, niemals jemandem zu erlauben, sich aus Audit- und Sicherheitsgründen direkt beim Root- / Administrator-Account anzumelden. Wenn Sie Root-Login direkt erlauben, wissen Sie nicht, wer sich angemeldet hat, von wem sie das Passwort erhalten haben usw. Aber wenn sich jemand in Jimmys Account anmeldet und seine Berechtigungen auf root erhöht, haben Sie eine bessere Idee, wo Sie anfangen sollen Audit-Suche (und das Konto, das zurückgesetzt werden soll).

Erlauben Sie Benutzern nur SSH, die sie benötigen Benutze die AllowUsers setting und explicity geben an, welche Konten den SSH-Zugriff benötigen. Dies wird standardmäßig alle anderen Konten von SSH blockieren.

Bearbeiten Sie Sudoers über visudo und erlauben Sie nur die Befehle, die der Benutzer benötigt. Es gibt eine Menge ausführlicher Anleitungen dazu, daher werde ich hier nicht näher darauf eingehen. Hier ist ein Vorspeise: http://ubuntuforums.org/showthread.php?t=1132821

Der Kern davon besteht darin, zu verhindern, dass ein kompromittierter Account Ihren Computer gefährdet. dh. Wenn Sallys Account beschädigt wird und Sally sudo nur zum Neustarten des Webservers verwenden kann, hat der Angreifer vielleicht Spaß daran, den Webserver in einer Schleife neu zu starten, aber zumindest nicht rm -rf /your/webserver/directory oder öffne alle deine Firewall-Ports, etc.

Richten Sie gute Firewall-Regeln ein, die nur die Ports zulassen, die für Ihre Box erforderlich sind. Im Allgemeinen möchten Sie alles fallen lassen und nur explizit erlauben, was Sie brauchen. Es gibt viele anständige iptables und andere Firewalls starten online, hier ist eine, die ich benutze (es ist ein grundlegender Starter):

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

Auch ein starkes Passwort ist der Schlüssel. Selbst wenn Sie SSH-Schlüssel für Ihren Fernzugriff verwenden, sollten Sie immer noch ein Passwort für die Nutzung von Sudo benötigen. Dies ist ein Fall, in dem Sudo mehr Sicherheit bieten könnte. Wenn jemand Ihre ssh-Schlüssel stehlen würde, wäre er immer noch daran gehindert, etwas Wichtiges auf Ihrer Box zu tun, wenn er Ihr Account-Passwort noch brutal erzwingen muss, um sudo zu verwenden. Passwörter sollten kein Wort sein, sondern eine Pass-Phrase. Denk an einen Satz und nutze das. Dies wird Ihnen in der Regel mehr als 8 Zeichen lang und bietet viel Entropie, ist aber auch leichter zu merken als ein zufälliges Passwort. Natürlich sagen gute Passwort-Praktiken, ein maschinell erzeugtes zufälliges Passwort zu verwenden, um Tools wie John the Ripper zu täuschen, die die meisten Passphrasen und Passwörter durchbrechen. Nein, das Ändern von E mit 3 funktioniert nicht, John bekommt auch diese Permutationen.


5
2018-03-10 19:54



Danke für eine umfassende Antwort! Ich muss definitiv alle diese Hinweise verwenden, um meine Boxen zu sichern. Ich werde die Antwort von EEAA dennoch akzeptieren, da sie etwas genauer ist als das, was ich gefragt habe. - Dmitry Pashkevich
@ DmitryPashkevich das ist OK, EEAA hat eine gute und passende Antwort. Du hast mich gebeten, meinen Kommentar oben zu erläutern, also tat ich es. Keine Bange :) - SnakeDoc
Wie für sudo su - und Variationen, sudoreplay könnte nützlich sein. - nyuszika7h


In einigen Fällen ist es notwendig, dies zu tun. z.B. Einige Hypervisor-APIs müssen passwortlos und passwortlos angemeldet sein sudo. Aber Sie können das immer noch einschränken, ohne zu brechen.

Für das, was Sie erreichen möchten. Ich würde sagen, gewöhnen Sie sich daran, ein Passwort einzugeben. Sicherheit ist hier bequemer als Bequemlichkeit. Außerdem, wenn Sie wirklich Root-Zugriff benötigen, können Sie verwenden sudo Die Anmeldeinformationen werden für kurze Zeit zwischengespeichert. Wenn Sie mehrere sudo-Befehle nacheinander ausführen, wird nur beim ersten Mal nach dem Kennwort gefragt. Es ist also keine so große Unannehmlichkeit, wie Sie annehmen.

Auch wenn Sie viele root-privilegierte Befehle eingeben und Sudo nicht ständig vor sich haben wollen, können Sie beides tun su oder sudo -s um eine root-Shell zu bekommen. Sie geben Ihr Passwort einmal ein und das war's.


3
2018-03-10 03:18





Ich wurde einmal von passwordless sudo gebissen. Es war ein Shell-Skript, ein Installer, der in meinem Namen Sudo genannt im Gegensatz zu, wissen Sie, nur Sudo oder Fehler erfordern.

Imaging gibt 'make' ein und das Skript macht 'sudo make install' für Sie, ohne den Basispfad zu setzen oder anzuzeigen, und das Skript wird von vornherein so gehackt, dass Sie nicht sicher sind, ob es / usr / local bekannt ist und so beginnst du / usr auf Modifikationen zu prüfen ...

Ich schwor mir, NOPASSWD nie wieder zu verwenden und änderte auch diese Timeout-Einstellung auf 0.


2
2017-10-17 00:05





Wenn Sie Ihre Frage nicht genau beantworten, können Sie auch eine längere Zeit einstellen timestamp_timeout Sie müssen also Ihr Passwort nicht so oft eingeben. Dadurch wird verhindert, dass jemand Administratorrechte erhält, sondern Ihren Ärger reduziert.

Von dem sudoers man page:

timestamp_timeout

Anzahl der Minuten, die verstreichen können, bis sudo erneut nach einem Passwd fragt. Das Timeout kann eine gebrochene Komponente enthalten, wenn die minimale Granularität nicht ausreicht.   zum Beispiel 2.5. Der Standardwert ist 5. Setzen Sie dies auf 0, um immer nach einem Passwort zu fragen. Wenn der Wert auf einen Wert kleiner als 0 gesetzt ist, läuft der Zeitstempel des Benutzers niemals ab. Diese   kann verwendet werden, um Benutzern das Erstellen oder Löschen eigener Zeitstempel über "sudo -v" bzw. "sudo -k" zu ermöglichen.

Dieser Blogpost zeigt einige Beispiele verwenden visudo um das Zeitlimit in Minuten festzulegen, z. B .:

Defaults timestamp_timeout=60

Vielleicht ist dies eine glückliche Mitte zwischen Sicherheit und Benutzerfreundlichkeit?


1
2017-09-05 03:52



Danke für die Eingabe! Meine ursprüngliche Frage war, dass ich niemals ein Passwort verwenden (und mich daran erinnern) muss, da Sie Schlüssel verwenden können, um in die Maschine zu gelangen, und nicht, wie oft ich dazu aufgefordert werde. Andere Leute haben deutlich gemacht, dass das eine schlechte Idee ist. - Dmitry Pashkevich