Ist es in Ordnung, "sudo" ohne Passwort auf einem Cloud-Server einzurichten?

Ich mag die Idee, auf Server über Schlüssel zuzugreifen, so dass ich mein Passwort nicht jedes Mal eingeben muss, wenn ich sshin eine Box komme. Ich sperre sogar das rootPasswort meines Benutzers (nicht ) ( passwd -l username), so dass es unmöglich ist , sich ohne Schlüssel anzumelden.

All dies funktioniert jedoch nicht, wenn ich ein Kennwort für sudoBefehle eingeben muss. Daher bin ich versucht, passwordless sosudo einzurichten , dass es dem passwortlosen Login entspricht.

Ich habe jedoch immer noch das Gefühl, dass es auf unerwartete Weise nach hinten losgeht, es scheint nur irgendwie unsicher zu sein. Gibt es irgendwelche Einschränkungen bei solchen Einstellungen? Würden Sie dies für ein Benutzerkonto auf einem Server empfehlen / nicht empfehlen?

Klarstellungen

1. Ich spreche hier von der Verwendung sudoin einer interaktiven Benutzersitzung, nicht für Dienste oder Verwaltungsskripte
2. Ich spreche über die Verwendung eines Cloud-Servers (daher habe ich keinen physischen lokalen Zugriff auf einen Computer und kann mich nur remote anmelden)
3. Ich weiß, dass sudoeine Zeitüberschreitung vorliegt, in der ich mein Passwort nicht erneut eingeben muss. Aber bei meinem Konzert geht es nicht wirklich darum, die zusätzliche Zeit für die Eingabe eines Passworts zu verschwenden. Meine Idee war jedoch, überhaupt kein Passwort haben zu müssen, da ich davon ausgehe, dass:
   • Wenn ich es mir merken muss, ist es sehr wahrscheinlich zu kurz, um sicher zu sein oder wiederverwendet zu werden
   • Wenn ich ein langes und eindeutiges Passwort für mein Remote-Konto generiere, muss ich es irgendwo speichern (ein lokales Passwort-Manager-Programm oder einen Cloud-Dienst) und jedes Mal abrufen, wenn ich es verwenden möchte sudo. Ich hoffte, ich könnte das vermeiden.

Mit dieser Frage wollte ich die Risiken, Vorbehalte und Nachteile einer möglichen Konfiguration gegenüber den anderen besser verstehen.

Follow-up 1

Alle Antworten besagen, dass passwortlos sudounsicher ist, da es eine "einfache" Eskalation von Berechtigungen ermöglicht, wenn mein persönliches Benutzerkonto kompromittiert wird. Ich verstehe das. Wenn ich hingegen ein Passwort verwende, gehen wir mit Passwörtern alle klassischen Risiken ein (zu kurze oder gemeinsame Zeichenfolge, die über verschiedene Dienste hinweg wiederholt wird usw.). Aber ich denke, wenn ich die Kennwortauthentifizierung deaktiviere, /etc/ssh/sshd_configdamit Sie immer noch einen Schlüssel zum Anmelden haben, kann ich ein einfacheres Kennwort verwenden, nur um dies einfacher einzugeben sudo. Ist das eine gültige Strategie?

Follow-up 2

Wenn ich auch einen Schlüssel für die Anmeldung rootüber ssh habe, jemand Zugriff auf meinen Computer hat und meine Schlüssel stiehlt (der ist jedoch immer noch durch das Schlüsselbundkennwort des Betriebssystems geschützt!), Kann er auch einen direkten Zugriff auf das rootKonto erhalten , den sudoWeg umgehen . Wie sollte dann die Richtlinie für den Zugriff auf das rootKonto aussehen?

Ich mag die Idee, auf Server über Schlüssel zuzugreifen, so dass ich mein Passwort nicht jedes Mal eingeben muss, wenn ich in eine Box ssh, ich sperre sogar das Passwort meines Benutzers (nicht root) (passwd -l Benutzername), so dass es unmöglich ist Ohne Schlüssel einloggen ... Würden Sie dies für ein Benutzerkonto auf einem Server empfehlen / nicht empfehlen?

Sie deaktivieren passwortbasierte Anmeldungen auf die falsche Weise. Anstatt ein Benutzerkonto zu sperren, legen Sie PasswordAuthentication noin Ihrem /etc/ssh/sshd_config.

Mit dieser Einstellung ist die Kennwortauthentifizierung für ssh deaktiviert, Sie können jedoch weiterhin ein Kennwort für sudo verwenden.

Das einzige Mal , dass ich empfehlen , NOPASSWDin sudo ist für Dienstkonten, denen Prozesse in der Lage sein müssen programmatisch Befehle über sudo auszuführen. Stellen Sie unter diesen Umständen sicher, dass Sie explizit nur die spezifischen Befehle auf die Whitelist setzen, die das Konto ausführen muss. Bei interaktiven Konten sollten Sie Kennwörter immer aktiviert lassen.

Antworten auf Ihre Anschlussfragen:

Aber ich denke, wenn ich die Kennwortauthentifizierung in / etc / ssh / sshd_config deaktiviere, damit Sie immer noch einen Schlüssel zum Anmelden haben, kann ich ein einfacheres Kennwort nur für sudo verwenden, das einfacher einzugeben ist? Ist das eine gültige Strategie?

Ja das ist richtig. Ich empfehle immer noch, relativ starke lokale Kontokennwörter zu verwenden, aber nicht lächerlich stark. ~ 8 zufällig generierte Zeichen sind ausreichend.

Wenn ich auch einen Schlüssel habe, um mich als root über ssh anzumelden, wenn jemand Zugriff auf meinen Computer erhält und meine Schlüssel stiehlt (sie sind jedoch immer noch durch das Schlüsselbundkennwort des Betriebssystems geschützt!), Kann er genauso gut einen direkten Zugriff auf das erhalten Root-Konto unter Umgehung des sudo-Pfads.

Der Root-Zugriff über ssh sollte deaktiviert sein. Zeitraum. Stellen Sie PermitRootLogin noin Ihr sshd_config.

Wie sollte dann die Richtlinie für den Zugriff auf das Root-Konto lauten?

Sie sollten immer die Möglichkeit haben, einen bandexternen Zugriff auf die Konsole Ihres Servers zu erhalten. Dies wird von mehreren VPS-Anbietern bereitgestellt, ebenso wie von Anbietern dedizierter Hardware. Wenn Ihr Provider keinen echten Konsolenzugriff gewährt (z. B. EC2), können Sie den Zugriff in der Regel mithilfe eines Prozesses wie dem in dieser Antwort beschriebenen wiederherstellen .

Im Allgemeinen beschränke ich die Verwendung NOPASSWORDauf Befehle, die von einem automatisierten Prozess ausgeführt werden. Es ist vorzuziehen, ein Dienstkonto für diese Befehle zu haben und die Verwendung von sudo auf die erforderlichen Befehle zu beschränken.

Wenn Sie NOPASSWORDallgemeine Befehle zulassen , kann jeder, der Zugriff auf Ihre Benutzer-ID erhält, Befehle ausführen. Dies kann auf eine Gefährdung Ihrer Anmeldeinformationen zurückzuführen sein, kann aber auch so einfach sein, als würde jemand an Ihrem Schreibtisch sitzen, wenn Sie sich für eine Sekunde zurückziehen.

Ich muss mein Passwort nicht so oft eingeben. Sobald Sie Ihr Passwort eingegeben haben, können Sie mehrere Befehle ausführen, wenn Sie nicht zu lange zwischen ihnen warten. Das Timeout ist konfigurierbar.

Ich würde dies nur unter zwei Umständen verwenden:

• Wenn es für ein automatisiertes Skript, das als bestimmter Benutzer ausgeführt wird, unbedingt erforderlich ist
• Für bestimmte Administrationsaufgaben (schreibgeschützte Administrationsaufgaben, nicht solche, die Maßnahmen zur Änderung des Systems ergreifen) und dann natürlich nur für bestimmte Benutzer

Standardmäßig werden Sie die meisten sudoKonfigurationen in derselben Sitzung eine Weile lang nicht mehr danach fragen (wenn Sie eine neue Shell öffnen, die keine Auswirkungen hat). Sie können dieses Verhalten bis zu einem gewissen Grad mit der timestamp_timeoutEinstellung steuern .

Passwortlos sudoist nicht annähernd so gefährlich wie passwortlose sshSchlüssel, da ein entfernter Angreifer zunächst Ihre Anmeldeinformationen benötigt, diese jedoch durch eine Beeinträchtigung Ihres privaten Schlüssels eingegangen sind (oder sich physisch in Ihrer Nähe befinden) Wenn Sie angemeldet und entsperrt sind, während Sie sich nicht am Computer befinden, ist die Kennwortanforderung ein wertvoller zusätzlicher Schutz für den Benutzer und den privilegierten Zugriff.

In Bezug auf Follow-up 2:

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

Dies sollte auch aus genau dem Grund vermieden werden, den Sie beschreiben. Wenn eine Remoteverbindung privilegierten Zugriff haben muss, muss sie sich über ein Dienstkonto anmelden und diese gerade so steuern, dass sie ihre Aufgabe über sudo erledigt. Dies ist natürlich einfacher zu konfigurieren, so dass sich viele nicht darum kümmern (was zu Ihren Gunsten ist, wenn Sie dies tun, da es viel weniger hängendes Obst gibt als Sie, für das Angreifer dort Zeit aufwenden können!) Uralter Kompromiss zwischen Sicherheit und Komfort (Tipp: Sicherheit wählen!).

Sie können das Beste aus beiden Welten genießen: SSH-Authentifizierung für Login und für sudo. Wenn Sie das Modul pam_ssh_agent_auth einbinden , können Sie SSH-Schlüssel zur Authentifizierung verwenden, ohne ein Kennwort anzugeben, wenn Sie sudo verwenden.

Ich benutze dies seit mehr als fünf Jahren in der Produktion.

Um es zu konfigurieren, installieren Sie das PAM-Modul und fügen Sie dann eine Zeile /etc/pam.d/sudooder eine entsprechende Zeile zu Ihrem System hinzu:

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

Wenn Sie dies tun, müssen Sie Ihre Schlüssel auf Ihrem Computer mit einer Passphrase schützen. Auf diese Weise müsste jemand in Ihren Computer eindringen und die Schlüssel stehlen, um hineinzukommen. Er könnte dies tun, indem er sie aus dem Speicher zieht, während er entsperrt ist, wenn er Zugriff auf Ihr Konto hat, indem er Ihre Passphrase knackt oder Ihre Passphrase stiehlt ein Keylogger oder eine Schulter, die es surft, während Sie es eingeben (schauen Sie hinter sich!).

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

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

Da Sie gefragt haben, hier ist mein allgemeiner Rat, wie Sie das sudoProblem angehen können.

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

Ein richtig eingerichtetes Sudo verwendet diese ALL=(ALL) ALLEinstellung nicht, sondern beschränkt sich eher auf das, was der Benutzer speziell benötigt. Wenn Sie beispielsweise benötigen, dass sich ein Benutzer anmeldet und einen blockierten Dienst neu startet, muss er möglicherweise nicht in der Lage sein, neue Software zu installieren oder Ihren Server herunterzufahren, Firewall-Regeln zu ändern usw.

Es ist manchmal üblich, dass Benutzer sudo verwenden, um sich zum Root-Konto zu erheben, d. H. sudo su -. Sobald sie das tun, hören Sie auf zu sehen, wer was über das Root-Konto tut (Root kann mehrfach gleichzeitig angemeldet sein). Manchmal möchten die Benutzer den sudo su -Befehl auch deaktivieren . Wenn Sie jedoch aus praktischen Gründen für die Verwaltung ein Konto mit vollständigen Root-Rechten benötigen, sudo su -protokolliert der Befehl zumindest, wer wann als Root-Rechter eingestuft wurde.

So sichere ich meine Boxen:

Ändern Sie den SSH-Port in einen anderen als den Standardport. Dies soll verhindern, dass die Dummköpfe, die nach Portnummern suchen, so lange wegschlagen, bis sie eintreffen (oder nicht).

Root-Anmeldung über SSH mit der AllowRootLogin noEinstellung in Ihrer sshd_config nicht zulassen. Dies verhindert, dass jemand brutal in Ihr Root-Konto eindringt. Es ist im Allgemeinen nur eine gute Praxis, aus Prüfungs- und Sicherheitsgründen niemals jemandem die direkte Anmeldung beim Root- / Administratorkonto zu gestatten. Wenn Sie die Root-Anmeldung direkt zulassen, wissen Sie nicht, von wem Sie sich angemeldet haben, von wem sie das Passwort erhalten haben usw. Wenn sich jedoch jemand in Jimmys Konto anmeldet und die Berechtigungen für die Root-Anmeldung erhöht, wissen Sie besser, wo Sie mit der Anmeldung beginnen sollen Audit-Suche (und wer ist Konto zum Zurücksetzen).

Erlauben Sie Benutzern nur SSH, wenn dies erforderlich ist. Verwenden Sie die AllowUsersEinstellung und geben Sie explizit an, welche Konten SSH-Zugriff benötigen. Dies blockiert standardmäßig alle anderen Konten von SSH.

Bearbeiten Sie Sudoer über Visudo und lassen Sie nur die Befehle zu, die der Benutzer benötigt. Es gibt viele ausführliche Anleitungen, wie das geht, daher werde ich hier nicht näher darauf eingehen. Hier ist ein Starter: http://ubuntuforums.org/showthread.php?t=1132821

Damit soll verhindert werden, dass ein kompromittiertes Konto Ihren Computer gefährdet. dh Wenn Sallys Konto aufgebrochen wird und Sally nur sudo zum Neustarten des Webservers verwenden kann, hat der Angreifer möglicherweise Spaß daran, den Webserver in einer Schleife neu zu starten, kann er jedoch nicht rm -rf /your/webserver/directoryalle Firewall-Ports usw. öffnen.

Richten Sie gute Firewall-Regeln ein, die nur die Ports zulassen, die für den Betrieb Ihrer Box erforderlich sind. Im Allgemeinen möchten Sie alles löschen und nur explizit zulassen, was Sie benötigen. Es gibt eine Menge anständiger iptables und andere Firewalls, die online gestartet werden. Ich verwende hier eine (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.Auch wenn Sie SSH-Schlüssel für den Remotezugriff verwenden, sollten Sie für die Verwendung von Sudo ein Kennwort benötigen. Dies ist ein Fall, in dem sudo etwas mehr Sicherheit bieten könnte. Wenn jemand Ihre SSH-Schlüssel stehlen würde, würde er trotzdem daran gehindert, etwas Bedeutendes auf Ihrer Box zu tun, wenn er Ihr Kontopasswort brutal erzwingen müsste, um sudo zu verwenden. Passwörter sollten kein Wort, sondern eine Passphrase sein. Denken Sie an einen Satz und verwenden Sie diesen. Dadurch erhalten Sie in der Regel etwas mehr als 8 Zeichen, was eine Menge Entropie bietet, aber auch leichter zu merken ist als ein zufälliges Passwort. Natürlich wird nach bewährten Passwortpraktiken ein maschinengeneriertes Zufallspasswort verwendet, um Cracking-Tools wie John the Ripper zum Narren zu halten, die die meisten Passphrasen und Passwörter durchgehen. Nein, das Ändern von E mit 3 funktioniert nicht, John bekommt diese Permutationen ebenfalls.

In einigen Fällen ist dies erforderlich. Beispielsweise benötigen einige Hypervisor-APIs ein passwortloses Login und ein passwortloses Login sudo. Aber Sie können das immer noch einschränken, ohne zu brechen.

Für das, was Sie erreichen wollen. Ich würde sagen, gewöhne dich daran, ein Passwort einzugeben. Sicherheit ist hier praktischer als Bequemlichkeit. Außerdem können Sie, wenn Sie wirklich Root-Zugriff benötigen, sudodie Anmeldeinformationen für eine Weile zwischenspeichern. Wenn Sie also mehrere sudo-Befehle hintereinander ausführen, werden Sie nur beim ersten Mal zur Eingabe des Kennworts aufgefordert. Es ist also keine so große Unannehmlichkeit, wie Sie annehmen.

Auch wenn Sie in einer Menge root privilegierter Befehle sind die Eingabe und wollen nicht sudo setzen auf dem vor ihnen die ganze Zeit , können Sie entweder suoder sudo -sein Root - Shell zu erhalten. Sie werden Ihr Passwort einmal eingeben und dann ist es soweit.

Ich bin einmal von Sudo ohne Passwort gebissen worden. Es war ein Shell-Skript, ein Installationsprogramm, das sudo in meinem Namen anrief und nicht nur sudo oder Fehler benötigte.

Stellen Sie sich vor, Sie tippen 'make' und das Skript, das den 'sudo make install'-Teil für Sie ausführt, ohne den Basispfad festzulegen oder anzuzeigen, und das Skript ist an erster Stelle so verwirrend, dass Sie nicht sicher sind, ob Sie / usr / local kennen und so fängst du an, / usr auf Änderungen zu überprüfen ...

Ich habe mir geschworen, NOPASSWD nie wieder zu verwenden, und auch diese Zeitüberschreitungseinstellung auf 0 geändert.

Während Sie Ihre Frage nicht streng beantworten, können Sie auch eine längere festlegen, timestamp_timeoutdamit Sie Ihr Passwort nicht so oft eingeben müssen. Auf diese Weise wird verhindert, dass nur ein Benutzer Administratorrechte erhält, aber Ihr Ärger wird verringert.

Aus der sudoers-Manpage :

timestamp_timeout

Die Anzahl der Minuten, die vergehen können, bevor sudo erneut nach einem Passwort fragt. Das Timeout kann eine Teilkomponente enthalten, wenn die winzige Körnigkeit nicht ausreicht, beispielsweise 2,5. Der Standardwert ist 5. Setzen Sie diesen Wert auf 0, um immer zur Eingabe eines Kennworts aufzufordern. Bei einem Wert unter 0 läuft der Zeitstempel des Benutzers niemals ab. Dies kann verwendet werden, um Benutzern das Erstellen oder Löschen eigener Zeitstempel über "sudo -v" bzw. "sudo -k" zu ermöglichen.

Dieser Blog - Eintrag zeigt einige Beispiele mit visudodem Timeout in Minuten einzustellen, wie zum Beispiel:

Defaults timestamp_timeout=60

Vielleicht ist dies ein glücklicher Mittelweg zwischen Sicherheit und Benutzerfreundlichkeit?

Die anderen Antworten hier sind großartig und berühren die meisten wichtigen Punkte. Eine Sache, die ich nicht erwähnt habe, ist die Tatsache, dass jede Art von Authentifizierung, die Sie vornehmen, wenn Sie sich selbst anmelden, von einem entfernten Angreifer erfasst werden kann, der bereits in Ihrem Konto Fuß gefasst hat. Sie können Ihre Shell-Anmeldedateien oder PATH ändern, um einen Keylogger zu installieren, sodass alle Eingaben, einschließlich Ihres sudo-Passworts, an sie gesendet werden. Sie könnten Ihrem PATH eine gehackte Sudo-Binärdatei hinzufügen, um Ihr Passwort zu sammeln. Sie können die SSH-Agent-Verbindung zurück zu Ihrem Verbindungsrechner hijacken, um pam_ssh_agent_auth zu besiegen und sich selbst zu root zu machen, sobald Sie eine Verbindung herstellen. In Bezug auf die absolute Sicherheit sehe ich keinen Unterschied zwischen der Verwendung eines Passworts für sudo und nicht. Es macht es natürlich zu einem komplizierteren Angriff.

Zusammenfassend kann ich sagen, dass der einzige Weg, um zu verhindern, dass ein kompromittiertes Benutzerkonto root wird, wenn Sie sudo-Zugriff haben, darin besteht, den sudo-Zugriff von sich selbst zu entfernen oder ihn niemals zu verwenden. Wenn Sie nicht einverstanden sind, lassen Sie es mich wissen, da ich gerne falsch liegen würde!