Ich glaube, dass eine geeignete Lösung für die meisten einfachen Fälle [dh wenn ein Framework wie Puppet/Chef/CfEngine/Ansible zu viel des Guten ist], aber ein hohes Maß an Kontrolle über das Remote-System erforderlich ist,
(a) Erfordern Sie eine schlüsselbasierte Authentifizierung (b) Sperren Sie die Standorte, die von SSH verwendet werden können – insbesondere, um die IP-Adressen zu sperren, die Root-Benutzer verwenden können (c) Stellen Sie sicher, dass die Computer mit dieser Vertrauensbeziehung ordnungsgemäß gesichert sind.
Ich glaube nicht, dass "das Einloggen als Root verpönt ist", genauso wie "das Einloggen als Root, um Dinge zu tun, die keine Root-Berechtigungen erfordern" verpönt ist. Ein erratbares Passwort macht es möglich, dass das Konto brutal erzwungen wird, also ist das ein Problem, mit dem man sich auseinandersetzen muss, und indem man Leuten erlaubt, sich als root anzumelden, können sie dumme Fehler mit einem größeren Umfang machen und fragwürdige Dinge tun, die sich verbergen böswillige Aktivität - aber je nach Architektur ist dies möglicherweise nicht sinnvoll.
Dieser XKCD-Comic weist darauf hin, dass es je nach Umgebung möglicherweise keine Rolle spielt, ob ein Root-Konto kompromittiert wird.
Wahrscheinlich ist die einfachste und effektivste Lösung für den allgemeinen Fall, genau einzuschränken, wer sich als Root anmelden kann durch Kontrolle der Schlüssel in Verbindung mit der Angabe einer geeigneten AllowUsers-Zeile in /etc/ssh/sshd.conf. Eine geeignete Zeile, die normalen Benutzern erlaubt, aber den Root-Zugriff sperrt, könnte wie folgt aussehen:
AllowUsers normaluser1 normaluser2 [email protected]
Natürlich ist es wichtig, dass die passwortbasierte Anmeldung nicht erlaubt ist oder dass das Root-Konto kein Passwort hat (dh ein „!“ oder „*“ im Passwortfeld der Passwortdatei hat.)
Wie Sie postuliert haben, wenn nur ein einziges (oder eine kleine Anzahl von) Programmen ausgeführt werden muss, ist es möglicherweise besser, einen bestimmten Benutzer mit schlüsselbasierter Authentifizierung einzurichten und den entsprechenden sudo-Zugriff auf die erforderlichen Befehle zu gewähren.
Natürlich gibt es eine Menge Dinge, die getan werden können, um den Zugriff abhängig vom Wert der Daten weiter "zu sperren" - Selinux, Remote-Protokollierung, eingeschränkte Shell, Tageszeitbeschränkungen, sofortige Benachrichtigungen bei Anmeldungen , aktive Protokollüberwachung wie fail2ban [zusätzlich zu Netzwerkbeschränkungen, die ich als nicht optional betrachte] können alle Teil einer Lösung sein. Das heißt, wenn Sie einfach ein System steuern, das leicht umgehauen und neu erstellt werden kann, ist vieles davon wahrscheinlich übertrieben.
Bitte denken Sie daran, dass die Sicherheit in Schichten aufgebaut ist. Um Root-Zugriff zu erhalten, sollte ein Konto mehrere Schichten durchlaufen müssen. Das Sperren des Zugriffs, private SSH-Schlüssel, Firewalls, Tageszeitbeschränkungen [ und das Prinzip des geringsten Zugriffs, dh nur Zugriff auf das, was benötigt wird, nicht mehr, Protokollierung, Backups ] sollten alle zusammen als Teil einer guten Sicherheit funktionieren.
Zusätzlich – SUDO-Zugriff
Sudo ist ein Mechanismus, der es einem normalen Benutzer ermöglicht, bestimmte Befehle mit erhöhtem Zugriff auszuführen, und ist sehr flexibel und vielfältig im Umfang. Während ein Überblick über sudo hier nicht angebracht ist (aber gut dokumentiert ist, wenn Sie man sudo eingeben In den meisten Distributionen könnten die entsprechenden Schritte -
sein-
/etc/sudoers bearbeiten - Die meisten Linux-Varianten haben dafür ein spezielles Programm namens "visudo", das als root ausgeführt werden muss und ungefähr der Verwendung des System-Editors zum Bearbeiten von /etc/sudoers entspricht (was eine andere Möglichkeit ist). dies - obwohl wahrscheinlich darauf gestoßen ist)
-
Fügen Sie entsprechende Zeilen hinzu/ändern Sie sie, damit ein bestimmter Benutzer bestimmte Dinge tun kann. Wenn Sie zum Beispiel möchten, dass sie beispielsweise Verzeichnisse einhängen können, ohne ein Passwort eingeben zu müssen, würden Sie eine Zeile wie :
eingebenusername ALL=/sbin/mount NOPASSWD: ALL
Um diesen Befehl dann auszuführen, würde der entsprechende Benutzer so etwas wie
ausführen sudo mount /dev/xxx /path/to/mount
Sie können mehrere Zeilen für mehrere Befehle auflisten, Gruppen statt Verwendungen verwenden - sudoers ist ein ziemlich flexibles Subsystem. In vielen Distributionen ist es auch möglich, Dateien mit Befehlen in einem Unterverzeichnis wie /etc/sudoers.d
hinzuzufügen
Das Folgende ist eine Antwort aus dem Unix Stackexchange-Post
So führen Sie einen ssh-Befehl aus der Ferne aus, einen sudo-Befehl ohne Passwort.
Mit dieser Methode kann der Administrator des Servers Ihrem Konto erlauben, einen Befehl als sudo
auszuführen ohne Angabe des Passworts. Der Befehl ist wahrscheinlich der Aufruf Ihres Skripts und darf nur unter Ihrem Konto ausgeführt werden. Da der zulässige Befehl vollständig angegeben ist, einschließlich Argumente, glaube ich, dass diese Methode ziemlich sicher ist.
Sie können sudo anweisen, das Passwort für einige Befehle zu überspringen.
z.B. in /etc/sudoers
archemar ALL = (www-data) NOPASSWD: /bin/rm -rf /var/www/log/upload.*
dies darf ich verwenden
sudo -u www-data /bin/rm -rf /var/www/log/upload.*
als Archemar ohne Passwort.
Beachten Sie das
sudo -u www-data rm -rf /var/www/log/upload.*
funktioniert nicht (fragt nach einem Passwort) als rm
unterscheiden sich von /bin/rm
.
Achten Sie darauf, /etc/sudoers
zu bearbeiten mit visudo
Befehl.
Sobald Sie das fortgeschrittene Niveau erreicht haben, möchten Sie vielleicht Ihre eigene sudo
haben Dateien in /etc/sudoers.d
.