Lösung 1:
Ich liebe die Idee, über Schlüssel auf Server zuzugreifen, damit ich nicht jedes Mal mein Passwort eingeben muss, wenn ich in eine Box ssh, ich sperre sogar das Passwort meines Benutzers (nicht root) (passwd -l Benutzername), sodass es unmöglich ist, sich anzumelden inohne einen Schlüssel...Würden Sie empfehlen/nicht empfehlen, dies für ein Benutzerkonto auf einem Server zu tun?
Sie deaktivieren passwortbasierte Anmeldungen auf die falsche Weise. Anstatt das Konto eines Benutzers zu sperren, legen Sie PasswordAuthentication no fest in Ihrem /etc/ssh/sshd_config .
Mit dieser Einstellung ist die Passwortauthentifizierung für ssh deaktiviert, aber Sie können immer noch ein Passwort für sudo verwenden.
Die nur Zeit empfehle ich die Einstellung NOPASSWD in sudo ist für Dienstkonten, bei denen Prozesse in der Lage sein müssen, Befehle über sudo programmgesteuert auszuführen. Stellen Sie unter diesen Umständen sicher, dass Sie nur die bestimmten auf die weiße Liste setzen Befehle, die das Konto ausführen muss. Bei interaktiven Konten sollten Sie immer Passwörter aktiviert lassen.
Antworten auf Ihre Folgefragen:
Aber ich denke, wenn ich die Passwortauthentifizierung in/etc/ssh/sshd_config deaktiviere, sodass Sie immer noch einen Schlüssel zum Anmelden benötigen, kann ich ein einfacheres Passwort 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 Passwörter für lokale Konten zu verwenden, aber nicht lächerlich stark. ~8 Zeichen, zufällig generiert ist ausreichend.
Wenn ich auch einen Schlüssel habe, um mich über ssh als root anzumelden, wenn jemand auf meinen Computer zugreift und meine Schlüssel stiehlt (sie sind jedoch immer noch durch das Schlüsselbundpasswort des Betriebssystems geschützt!), kann er genauso gut einen direkten Zugriff auf das root-Konto erhalten, den sudo-Pfad umgehen.
Der Root-Zugriff über ssh sollte deaktiviert werden. Zeitraum. Stellen Sie PermitRootLogin no ein in Ihrem sshd_config .
Wie sollte dann die Richtlinie für den Zugriff auf das Root-Konto aussehen?
Sie sollten immer über eine Möglichkeit verfügen, Out-of-Band-Zugriff auf die Konsole Ihres Servers zu erhalten. Mehrere VPS-Anbieter bieten dies an, ebenso wie Anbieter dedizierter Hardware. Wenn Ihr Anbieter keinen echten Konsolenzugriff gewährt (z. B. EC2), können Sie den Zugriff in der Regel immer noch wiederherstellen, indem Sie einen Prozess wie den in dieser Antwort skizzierten verwenden.
Lösung 2:
Ich schränke die Verwendung von NOPASSWORD generell ein auf 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.
NOPASSWORD zulassen erlaubt für allgemeine Befehle jedem, der Zugriff auf Ihre Benutzer-ID erhält, alle Befehle auszuführen. Dies kann aus einer Kompromittierung Ihrer Anmeldeinformationen resultieren, kann aber auch so einfach sein wie jemand, der an Ihrem Schreibtisch sitzt, wenn Sie sich für eine Sekunde zurückziehen.
Ich finde, ich muss mein Passwort nicht so oft eingeben. Sobald Sie Ihr Passwort eingegeben haben, können Sie mehrere Befehle ausführen, wenn Sie zwischen ihnen nicht zu lange warten. Das Timeout ist konfigurierbar.
Lösung 3:
Sie können das Beste aus beiden Welten haben:SSH-Authentifizierung sowohl für die Anmeldung als auch für sudo. Wenn Sie das pam_ssh_agent_auth-Modul integrieren, können Sie SSH-Schlüssel verwenden, um sich zu authentifizieren, ohne ein Passwort anzugeben, wenn Sie sudo.
Ich verwende dies seit mehr als fünf Jahren in der Produktion.
Um es zu konfigurieren, installieren Sie das PAM-Modul und fügen dann eine Zeile zu /etc/pam.d/sudo hinzu oder das Äquivalent Ihres Systems:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
Achten Sie in diesem Fall darauf, Ihre Schlüssel auf Ihrem Computer mit einer Passphrase zu schützen. Auf diese Weise müsste jemand in Ihren Computer einbrechen 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 durch ein Keylogger oder Schultersurfen, während Sie es eingeben (schauen Sie hinter sich!).
Sie können denselben SSH-Schlüssel wie für die Anmeldung verwenden, oder Sie können einen separaten Schlüssel einrichten, den Sie Ihrem Agenten nur hinzufügen, wenn Sie sudo ausführen. Wenn Sie also besonders vorsichtig sein möchten, können Sie eine separate Datei „authorized_keys“ verwalten, die einen separaten SSH-Schlüssel enthält, den Sie nur dann zu Ihrem Agenten hinzufügen, wenn Sie sudo:
ausführen müssenauth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo
Lösung 4:
Ich würde dies nur unter zwei Umständen verwenden:
- Wenn es absolut ist erforderlich für ein automatisiertes Skript, das von einem bestimmten Benutzer ausgeführt wird
- Für bestimmte Admin-Aufgaben (schreibgeschützte Admin-Aufgaben, nicht solche, die Maßnahmen ergreifen, um das System zu ändern) und dann natürlich nur für bestimmte Benutzer
Standardmäßig sind die meisten sudo Konfigurationen werden Sie in derselben Sitzung für eine Weile nicht erneut fragen (wenn Sie eine neue Shell öffnen, die keine Auswirkung hat). Mit dem timestamp_timeout können Sie dieses Verhalten in gewissem Umfang steuern Einstellung.
Passwortloses sudo ist nicht annähernd so gefährlich wie ssh ohne Passphrase Schlüssel, da ein entfernter Angreifer Ihre Zugangsdaten benötigt, um überhaupt hineinzukommen, aber wenn er Ihren privaten Schlüssel irgendwie kompromittiert hat (oder wenn er sich physisch in Ihrer Nähe befindet und Sie sich während Ihrer Abwesenheit angemeldet und entsperrt haben von der Maschine), dann ist die Passwortabfrage eine wertvolle zusätzliche Verteidigung zwischen ihnen und dem privilegierten Zugriff.
Bezüglich Follow-up 2:
Wenn ich auch einen Schlüssel habe, um mich als root über ssh anzumelden
Dies wird am besten vermieden, genau aus dem Grund, den Sie beschreiben. Wenn eine Remote-Verbindung privilegierten Zugriff haben muss, melden Sie sich über ein Dienstkonto an und geben Sie diesem gerade genug Kontrolle, um seine Arbeit über sudo zu erledigen. Dies ist natürlich schwieriger zu konfigurieren, so dass viele sich nicht darum kümmern (was zu Ihren Gunsten wirkt, wenn Sie dies tun, da es viele niedriger hängende Früchte als Sie gibt, mit denen Angreifer ihre Zeit verbringen können!), Also kommt es darauf an uralter Kompromiss zwischen Sicherheit und Komfort (Profi-Tipp:Wählen Sie Sicherheit!).
Lösung 5:
Da Sie gefragt haben, hier meine allgemeinen Ratschläge, wie Sie mit sudo umgehen Problem.
Sudo wurde nicht entwickelt, um mehr Sicherheit zu bieten (obwohl es in gewisser Hinsicht möglich ist), sondern um einen guten Audit-Trail darüber zu liefern, wer was auf Ihrem System mit welchen Rechten tut.
Ein richtig eingerichtetes Sudo verwendet nicht den ALL=(ALL) ALL Einstellung, sondern eher etwas, das auf das beschränkt ist, was der Benutzer speziell benötigt. Wenn Sie zum Beispiel einen Benutzer benötigen, der sich anmelden und einen blockierten Dienst neu starten kann, benötigt er wahrscheinlich nicht die Möglichkeit, neue Software zu installieren oder Ihren Server herunterzufahren, Firewall-Regeln zu ändern usw.
Es ist manchmal üblich, dass Leute sudo verwenden, um sich zum Root-Konto zu erheben, dh. sudo su - . Sobald sie das tun, sehen Sie nicht mehr, wer was vom Root-Konto aus tut (Root kann mehrere Male gleichzeitig angemeldet sein). Manchmal möchten Leute also sudo su - deaktivieren auch befehlen. Aber aus praktischen Gründen, wenn Sie ein voll root-privilegiertes Konto für die Verwaltung benötigen, lassen Sie sich zumindest von jemandem den sudo su - ausstellen Der Befehl würde protokollieren, wer wann zum Root erhoben wurde.
So sichere ich meine Kartons:
Ändern Sie den SSH-Port auf einen anderen als den Standardport. Dies dient dazu, die dummen Bots zu vermeiden, die nach Portnummern suchen und dann weghämmern, bis sie reinkommen (oder nicht).
Root-Anmeldung über SSH mit AllowRootLogin no nicht zulassen Einstellung in Ihrer sshd_config. Dies verhindert, dass jemand Brute Force in Ihr Root-Konto eindringt. Es ist nur allgemein eine gute Praxis, aus Audit- und Sicherheitsgründen niemals jemandem zu erlauben, sich direkt beim Root-/Administratorkonto anzumelden. Wenn Sie die Root-Anmeldung direkt zulassen, wissen Sie nicht, wer sich angemeldet hat, von wem er das Passwort hat usw. Wenn sich jedoch jemand bei Jimmys Konto anmeldet und dann seine Berechtigungen auf Root erhöht, haben Sie eine bessere Vorstellung davon, wo Sie Ihre beginnen sollen Prüfungssuche (und wessen Konto zurückgesetzt werden soll).
Nur Benutzern SSH erlauben, die dies erfordern Verwenden Sie den AllowUsers Einstellung und geben Sie explizit an, welche Konten SSH-Zugriff benötigen. Dadurch werden standardmäßig alle anderen Konten von SSH blockiert.
Bearbeiten Sie Sudoer über visudo und lassen Sie nur die Befehle zu, die der Benutzer benötigt. Es gibt viele ausführliche Anleitungen, wie man das macht, also werde ich hier nicht näher darauf eingehen. Hier ist ein Starter:http://ubuntuforums.org/showthread.php?t=1132821
Das Wesentliche dabei ist, zu verhindern, dass ein kompromittiertes Konto Ihren Computer gefährdet. dh. Wenn in Sallys Konto eingebrochen wird und Sally nur sudo verwenden kann, um den Webserver neu zu starten, hat der Angreifer vielleicht Spaß daran, Ihren Webserver in einer Schleife neu zu starten, aber er kann zumindest nicht rm -rf /your/webserver/directory oder öffnen Sie alle Ihre Firewall-Ports usw.
Richten Sie gute Firewall-Regeln ein, die nur die Ports zulassen, die für den Betrieb Ihrer Box erforderlich sind. Im Allgemeinen möchte man alles fallen lassen und nur explizit zulassen, was man braucht. Es gibt viele anständige iptables und andere Firewall-Starts online, hier ist eine, die ich verwende (es ist ein einfacher 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 Ihren Fernzugriff verwenden, sollten Sie dennoch ein Passwort für die Sudo-Nutzung 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äre er immer noch daran gehindert, irgendetwas Wichtiges auf Ihrer Box zu tun, wenn er Ihr Kontopasswort immer noch brutal erzwingen muss, um sudo zu verwenden. Passwörter sollten kein Wort sein, sondern eine Passphrase. Denken Sie sich einen Satz aus und verwenden Sie diesen. Dadurch erhalten Sie im Allgemeinen etwas mehr als 8 Zeichen lang, was viel Entropie bietet, aber auch leichter zu merken ist als ein zufälliges Passwort. Gute Passwortpraktiken besagen natürlich, ein maschinell generiertes Zufallspasswort zu verwenden, um Cracking-Tools wie John the Ripper zu täuschen, die die meisten Passphrasen und Passwörter durchbrechen. Nein, das Ändern von E durch 3 funktioniert nicht, John bekommt diese Permutationen auch.