Mehrere Linux-Systemadministratoren arbeiten als Root

40

In unserem Team haben wir drei erfahrene Linux-Systemadministratoren, die ein paar Dutzend Debian-Server verwalten müssen. Bisher haben wir alle als Root mit der SSH-Authentifizierung mit öffentlichem Schlüssel gearbeitet. Wir hatten jedoch eine Diskussion darüber, was die beste Vorgehensweise für dieses Szenario ist, und konnten uns auf nichts einigen.

Jeder öffentliche SSH-Schlüssel wird in ~ root / .ssh / authorized_keys2 abgelegt

  • Vorteil: Einfach zu bedienen, SSH-Agent-Weiterleitung funktioniert problemlos, geringer Overhead
  • Nachteil: Fehlende Audits (Sie wissen nie, welche "Wurzel" eine Änderung vorgenommen hat), Unfälle sind wahrscheinlicher

Verwenden von personalisierten Konten und Sudo

Auf diese Weise würden wir uns mit personalisierten Konten mit öffentlichen SSH-Schlüsseln anmelden und sudo verwenden , um einzelne Aufgaben mit Root- Berechtigungen auszuführen . Außerdem können wir uns die Gruppe "adm" geben, mit der wir Protokolldateien anzeigen können.

  • Vorteil: Gutes Auditing, sudo verhindert, dass wir zu leicht idiotische Dinge tun
  • Nachteil: Die Weiterleitung von SSH-Agenten bricht ab. Dies ist problematisch, da kaum etwas als Nicht-Root ausgeführt werden kann

Verwendung mehrerer UID 0-Benutzer

Dies ist ein sehr einzigartiger Vorschlag von einem der Sysadmins. Er schlägt vor, drei Benutzer in / etc / passwd zu erstellen, die alle UID 0, aber unterschiedliche Anmeldenamen haben. Er behauptet, dass dies nicht verboten sei und dass jeder die UID 0 haben dürfe, aber trotzdem auditieren könne.

  • Vorteil: Die Weiterleitung von SSH-Agenten funktioniert, die Überwachung funktioniert möglicherweise (ungetestet), kein Sudo- Ärger
  • Nachteil: fühlt sich ziemlich schmutzig an - konnte es nirgends als zulässige Weise dokumentiert finden

Was würdest du vorschlagen?

Signum
quelle
2
Zu Ihrer Aussage "Es wurde nirgendwo als zulässiger Weg dokumentiert": Sehen Sie sich das -oFlag auf der useraddHandbuchseite an. Mit diesem Flag können mehrere Benutzer dieselbe Benutzer-ID verwenden.
Juli
6
Können Sie erklären, was Sie unter "SSH-Agent-Weiterleitungspausen" in der zweiten Option verstehen? Wir verwenden dies bei meiner Arbeit und die Weiterleitung von SSH-Agenten funktioniert einwandfrei.
Patrick
4
Sie sollten nicht von sudo aus, sondern von Ihrem Nicht-Root-Account aus sshgen.
Random832
4
Eine weitere Konsequenz der sudo-Methode: Sie können nicht mehr SCP / FTP als root verwenden. Alle Dateiübertragungen müssen zuerst in das Home-Verzeichnis der Person verschoben und dann im Terminal kopiert werden. Dies ist je nach Perspektive ein Vorteil und ein Nachteil.
user606723
1
Warum werden Puppen- / Koch- / Ansible-Systeme nicht berücksichtigt?
Alex Holst

Antworten:

64

Die zweite Option ist meiner Meinung nach die beste. Persönliche Accounts, Sudo-Zugang. Deaktivieren Sie den Root-Zugriff über SSH vollständig. Wir haben ein paar hundert Server und ein halbes Dutzend Systemadministratoren, so machen wir das.

Wie bricht die Agentenweiterleitung genau ab?

Auch wenn es so mühsam ist, sudovor jeder Aufgabe etwas zu tun, können Sie mit eine Sudo-Shell aufrufen sudo -soder mit zu einer Root-Shell wechselnsudo su -

thepearson
quelle
10
Anstatt den Root-Zugriff durch SSH vollständig zu deaktivieren, empfehle ich, für den Root-Zugriff durch SSH Schlüssel erforderlich zu machen, einen Schlüssel mit einer sehr starken Schlüsselphrase zu erstellen und ihn nur für den Notfall gesperrt zu lassen. Wenn Sie einen permanenten Konsolenzugriff haben, ist dies weniger nützlich, aber wenn Sie dies nicht tun, kann dies sehr praktisch sein.
EightBitTony
17
Ich empfehle aus Sicherheitsgründen die Root-Anmeldung über SSH zu deaktivieren. Wenn Sie wirklich als Root angemeldet sein müssen, melden Sie sich als Benutzer ohne Rootberechtigung und als Benutzer su an.
taz
+1 .. Ich würde weiter gehen als zu sagen "Die zweite Option ist die beste". Ich würde es die einzige vernünftige Option. Die Optionen eins und drei beeinträchtigen die Sicherheit des Systems sowohl vor Angriffen von außen als auch vor Fehlern erheblich. Außerdem ist # 2, wie das System entworfen wurde , um hauptsächlich verwendet zu werden.
Ben Lee
2
Bitte erläutern Sie weiter sudo -s. Habe ich Recht zu verstehen, dass sudo -ies keinen Unterschied zur Verwendung su -oder grundlegenden Anmeldung als Root gibt, abgesehen von zusätzlichen Protokolleinträgen im Vergleich zur normalen Root-Anmeldung? Wenn dies zutrifft, wie und warum ist es besser als eine einfache Root-Anmeldung?
PF4Public
9

In Bezug auf die dritte vorgeschlagene Strategie ist es useradd -o -u userXXXmir nicht vertraut, mehrere Benutzer als dieselbe Benutzer-ID auszuführen, außer die von @jlliagre empfohlenen Optionen zu prüfen. (Wenn Sie damit weitermachen, würde es mich interessieren, ob Sie den Beitrag bei auftretenden Problemen (oder Erfolgen) aktualisieren können ...)

Ich schätze, meine erste Beobachtung bezüglich der ersten Option "Der öffentliche SSH-Schlüssel eines jeden wird in ~ root / .ssh / authorized_keys2 abgelegt" ist, dass Sie absolut nie auf einem anderen System arbeiten werden;

  1. Dann müssen Sie zumindest zeitweise mit Benutzerkonten und arbeitensudo

Die zweite Beobachtung wäre, dass Sie, wenn Sie an Systemen arbeiten, die HIPAA, PCI-DSS-Konformität oder Dinge wie CAPP und EAL anstreben, die Probleme von sudo umgehen müssen, weil;

  1. Es ist ein Industriestandard , Nicht-Root-Einzelbenutzerkonten bereitzustellen, die überwacht, deaktiviert, abgelaufen usw. werden können, normalerweise unter Verwendung einer zentralen Benutzerdatenbank.

Damit; Verwenden von personalisierten Konten und Sudo

Es ist bedauerlich, dass fast alles, was Sie als Systemadministrator auf einem Remotecomputer tun müssen, erhöhte Berechtigungen erfordert. Es ist jedoch ärgerlich, dass die meisten SSH-basierten Tools und Dienstprogramme während Ihres Aufenthalts beschädigt werden sudo

Daher kann ich einige Tricks weitergeben, die ich benutze, um die von sudoIhnen erwähnten Unannehmlichkeiten zu umgehen. Das erste Problem besteht darin, dass PermitRootLogin=noSCP-Dateien zu einer Art PITA werden , wenn die Root-Anmeldung mit blockiert wird oder wenn Sie nicht über den Root-Schlüssel mit ssh verfügen.

Problem 1 : Sie möchten Dateien von der Remote-Seite scpen, benötigen jedoch Root-Zugriff. Sie können sich jedoch nicht direkt als Root bei der Remote-Box anmelden.

Langweilige Lösung : Kopieren Sie die Dateien in das Ausgangsverzeichnis, chown und scp down.

ssh userXXX@remotesystem, sudo su -Etc, cp /etc/somefileszu /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefileszu verwenden scp Dateien von Remote abzurufen.

Sehr langweilig.

Weniger langweilig Lösung : sftp unterstützt das -s sftp_serverFlag, daher können Sie wie folgt vorgehen (wenn Sie kennwortloses sudo in konfiguriert haben /etc/sudoers).

sftp  -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf 

(du kannst diesen hack-around auch mit sshfs benutzen, aber ich bin mir nicht sicher, ob er empfohlen wird ... ;-)

Wenn Sie keine Sudo-Rechte ohne Passwort haben oder die oben beschriebene Methode aus irgendeinem konfigurierten Grund nicht funktioniert, kann ich eine weitere, weniger langweilige Dateiübertragungsmethode für den Zugriff auf Remote-Root-Dateien vorschlagen.

Port Forward Ninja Methode :

Melden Sie sich beim Remote-Host an, aber geben Sie an, dass der Remote-Port 3022 (kann frei und nicht für Administratoren reserviert sein, dh> 1024) an Port 22 auf der lokalen Seite zurückgeleitet werden soll.

 [localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------

Holen Sie sich Wurzel in der normalen Art und Weise ...

-bash-3.2$ sudo su -
[root@remotehost ~]# 

Jetzt können Sie die Dateien in die andere Richtung scpen, ohne den langweiligen, langweiligen Schritt, eine Zwischenkopie der Dateien zu erstellen.

[root@remotehost ~]#  scp -o NoHostAuthenticationForLocalhost=yes \
 -P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password: 
resolv.conf                                 100%  
[root@remotehost ~]#  

 

 

Problem 2: SSH-Agentenweiterleitung : Wenn Sie das Root-Profil laden, z. B. durch Angabe einer Login-Shell, werden die für die SSH-Agentenweiterleitung erforderlichen Umgebungsvariablen SSH_AUTH_SOCKzurückgesetzt, daher ist die SSH-Agentenweiterleitung unter "defekt" sudo su -.

Halbgebackene Antwort :

Alles , was richtig eine Root - Shell lädt, wird zu Recht die Umwelt zurückzusetzen, jedoch gibt es eine leichte Behelfslösung Ihr Lieblings Einsatz , wenn Sie beide root - Berechtigung und die Fähigkeit , müssen Sie den SSH - Agenten zu verwenden , ZUGLEICH

Dies führt zu einer Art Chimären-Profil, das eigentlich nicht verwendet werden sollte, da es ein übler Hack ist , aber nützlich ist, wenn Sie Dateien vom Remote-Host als Root auf einen anderen Remote-Host übertragen müssen.

Auf jeden Fall können Sie aktivieren, dass Ihr Benutzer seine ENV-Variablen beibehalten kann, indem Sie in sudoers Folgendes festlegen:

 Defaults:userXXX    !env_reset

Auf diese Weise können Sie böse hybride Anmeldeumgebungen wie diese erstellen.

Login wie gewohnt;

[localuser@localmachine ~]$ ssh userXXX@remotehost 
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971

Erstellen Sie eine Bash-Shell, die ausgeführt wird /root/.profileund /root/.bashrc. aber bewahrtSSH_AUTH_SOCK

-bash-3.2$ sudo -E bash -l

Diese Shell hat also root- $PATHRechte und root (aber ein verschachteltes Home-Verzeichnis ...)

bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH
/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin

Sie können diesen Aufruf jedoch verwenden, um Dinge zu erledigen, die Remote-Sudo-Root erfordern, aber auch den SSH-Agentenzugriff wie folgt;

bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~
/root/.ssh/authorized_keys              100%  126     0.1KB/s   00:00    
bash-3.2# 
Tom H
quelle
1
Ich mag die Hacks.
Sjbotha
2

Die 3. Option sieht ideal aus - aber haben Sie es tatsächlich ausprobiert, um zu sehen, was passiert? Während Sie möglicherweise die zusätzlichen Benutzernamen im Authentifizierungsschritt sehen, wird bei jeder umgekehrten Suche derselbe Wert zurückgegeben.

Es ist keine gute Idee, Root-Direktzugriff auf SSH zuzulassen, auch wenn Ihre Computer nicht mit dem Internet verbunden sind oder starke Passwörter verwenden.

Normalerweise verwende ich 'su' anstelle von sudo für den Root-Zugriff.

symcbean
quelle
4
Das Hinzufügen mehrerer Benutzer mit derselben UID fügt Probleme hinzu. Wenn Anwendungen nach dem Benutzernamen für eine UID-Nummer suchen, können sie den falschen Benutzernamen suchen. Anwendungen, die unter root ausgeführt werden, können davon ausgehen, dass sie als der falsche Benutzer ausgeführt werden, und viele seltsame Fehler werden auftauchen (ich habe es einmal versucht).
Patrick
8
Die dritte Option ist nur eine verdammt schlechte Idee . Sie brechen im Wesentlichen die 1: 1-Beziehung zwischen UIDs und Benutzernamen, und buchstäblich erwartet alles in Unix, dass diese Beziehung gilt. Nur weil es keine ausdrückliche Regel gibt, dies nicht zu tun, heißt das noch lange nicht, dass es eine gute Idee ist.
Shadur
Sorry, aber die dritte Option ist eine schreckliche Idee. Wenn sich mehrere Benutzer mit UID 0 anmelden, müssen die Probleme nur vervielfacht werden. Option Nummer 2 ist die einzig vernünftige.
Doug
Die dritte Option verdient nicht so viele Ablehnungen. Es gibt keinen Befehl in Unix, von dem ich weiß, dass er durch diesen Trick verwirrt ist. Leute mögen es sein, aber Befehle sollten es nicht interessieren. Es ist nur ein anderer Anmeldename, aber sobald Sie angemeldet sind, wird der Vorname verwendet, der mit der UID in der Kennwortdatenbank übereinstimmt. Stellen Sie also sicher, dass der echte Benutzername (hier root) zuerst dort angezeigt wird.
Juli
@Patrick Hast du das in der Praxis gesehen? So viel ich getestet habe, wählen Anwendungen rootBenutzer aus, wenn rootBenutzer der erste Benutzer /etc/passwdmit UID 0 ist. Ich stimme mit jlliagre überein. Der einzige Nachteil, den ich sehe, ist, dass jeder Benutzer ein rootBenutzer ist und es manchmal verwirrend sein kann, zu verstehen, wer was getan hat.
Martin
2

Ich benutze (1), aber ich habe etwas eingegeben

rm -rf / tmp *

Ich kann sehen, dass es schlimm genug ist, wenn Sie mehr als eine Handvoll Admins haben.

(2) Ist wahrscheinlich ausgereifter - und Sie können durch sudo su vollwertige Wurzel werden -. Unfälle sind dennoch möglich.

(3) Ich würde nicht mit einem Lastkahnpfahl anfassen. Ich habe es auf Suns verwendet, um ein Nicht-Barebone-Sh-Root-Konto zu haben (wenn ich mich richtig erinnere), aber es war nie robust - und ich bezweifle, dass es sehr überprüfbar wäre.

Alien Lebensform
quelle
2

Antworte auf jeden Fall 2.

  1. Bedeutet, dass Sie SSH-Zugriff als zulassen root. Wenn diese Maschine in irgendeiner Weise öffentlich ist, ist dies nur eine schreckliche Idee; Als ich SSH auf Port 22 ausführte, hatte mein VPS mehrere Versuche pro Stunde, sich als root zu authentifizieren. Ich hatte ein grundlegendes IDS eingerichtet, um IPs zu protokollieren und zu sperren, bei denen mehrere Versuche fehlgeschlagen sind, aber sie kamen immer wieder. Zum Glück hatte ich den SSH-Zugriff als Root-Benutzer deaktiviert, sobald ich mein eigenes Konto und mein eigenes sudo konfiguriert hatte. Darüber hinaus haben Sie so gut wie keinen Audit-Trail.

  2. Ermöglicht den Root-Zugriff nach Bedarf. Ja, Sie haben als Standardbenutzer kaum Rechte, aber genau das möchten Sie. Wenn ein Account kompromittiert wird, möchten Sie, dass seine Fähigkeiten eingeschränkt werden. Sie möchten, dass ein Superuser-Zugriff eine erneute Kennworteingabe erfordert. Darüber hinaus kann der sudo-Zugriff über Benutzergruppen gesteuert und bei Bedarf auf bestimmte Befehle beschränkt werden, sodass Sie mehr Kontrolle darüber haben, wer auf was zugreifen kann. Darüber hinaus können Befehle, die als sudo ausgeführt werden, protokolliert werden, sodass ein viel besserer Prüfpfad bereitgestellt wird, wenn Probleme auftreten. Oh, und führen Sie nicht einfach "sudo su -" aus, sobald Sie sich angemeldet haben. Das ist eine schreckliche, schreckliche Übung.

  3. Die Idee Ihres Sysadmin ist schlecht. Und er sollte sich schlecht fühlen. Nein, * nix-Maschinen werden Sie wahrscheinlich nicht davon abhalten, aber sowohl Ihr Dateisystem als auch praktisch jede Anwendung erwartet von jedem Benutzer eine eindeutige UID. Wenn Sie diesen Weg beschreiten, kann ich Ihnen versichern, dass Sie auf Probleme stoßen. Vielleicht nicht sofort, aber irgendwann. Beispielsweise verwenden Dateien und Verzeichnisse trotz der Anzeige ansprechender Anzeigenamen UID-Nummern, um ihre Besitzer zu bestimmen. Wenn Sie auf ein Programm stoßen, das Probleme mit doppelten UIDs hat, können Sie später nicht einfach eine UID in Ihrer passwd-Datei ändern, ohne ernsthafte manuelle Bereinigungen des Dateisystems vornehmen zu müssen.

sudoist der Weg nach vorne. Es kann zusätzlichen Aufwand verursachen, wenn Befehle als Root ausgeführt werden, bietet Ihnen jedoch eine sicherere Box, sowohl in Bezug auf den Zugriff als auch in Bezug auf die Überwachung.

Rohaq
quelle
1

Auf jeden Fall Option 2, aber verwenden Sie Gruppen, um jedem Benutzer so viel Kontrolle wie möglich zu geben, ohne sudo verwenden zu müssen. sudo vor jedem Befehl verliert die Hälfte des Nutzens, weil Sie sich immer in der Gefahrenzone befinden. Wenn Sie die relevanten Verzeichnisse ohne sudo für die Sysadmins beschreibbar machen, kehren Sie sudo zu der Ausnahme zurück, durch die sich jeder sicherer fühlt.

julianisch
quelle
1

Früher gab es kein Sudo. Infolgedessen war es die einzige verfügbare Alternative, mehrere UID 0-Benutzer zu haben. Aber es ist immer noch nicht so gut, insbesondere mit der Protokollierung basierend auf der UID, um den Benutzernamen zu erhalten.

Heutzutage ist sudo die einzig geeignete Lösung. Vergiss alles andere.

Plumpsen
quelle
0

Es ist faktisch zulässig dokumentiert. BSD-Unices haben seit langer Zeit ihren Toor-Account und Bash-User werden in der Regel auf Systemen akzeptiert, auf denen csh Standard ist (akzeptiertes Fehlverhalten;)

Rackandboneman
quelle
0

Vielleicht bin ich komisch, aber Methode (3) kam mir auch zuerst in den Sinn. Vorteile: Sie hätten jeden Benutzernamen in den Protokollen und würden wissen, wer was als root getan hat. Nachteile: Sie sind die ganze Zeit Wurzeln, so dass Fehler katastrophal sein können.

Ich möchte fragen, warum Sie alle Administratoren benötigen, um root-Zugriff zu haben. Alle drei von Ihnen vorgeschlagenen Methoden haben einen entscheidenden Nachteil: Sobald ein Administrator eine sudo bash -loder mehrere Methoden ausführt sudo su -, verlieren Sie die Fähigkeit, nachzuverfolgen, wer was tut, und danach kann ein Fehler katastrophal sein. Im Falle eines möglichen Fehlverhaltens kann dies sogar noch viel schlimmer werden.

Vielleicht möchten Sie stattdessen einen anderen Weg einschlagen:

  • Erstellen Sie Ihre Administratorbenutzer als reguläre Benutzer
  • Entscheide, wer welchen Job machen muss (Apache Management / Postfix Management etc)
  • Hinzufügen von Benutzern zu verwandten Gruppen (z. B. Hinzufügen von "martin" zu "postfix" und "mail", "amavis", wenn Sie es verwenden usw.)
  • Berechtigungen korrigieren (chmod -R g + w postfix: postfix / etc / postfix)
  • gib nur relative sudo Potenzen an: (visudo -> lass martin /etc/init.d/postfix, / usr / bin / postsuper etc. verwenden)

Auf diese Weise wäre Martin in der Lage, Postfix sicher zu handhaben, und im Falle eines Fehlers oder Fehlverhaltens würden Sie nur Ihr Postfix-System verlieren, nicht den gesamten Server.

Dieselbe Logik kann auf jedes andere Subsystem wie Apache, MySQL usw. angewendet werden.

Natürlich ist dies zu diesem Zeitpunkt rein theoretisch und möglicherweise schwer einzurichten. Es sieht nach einem besseren Weg aus. Zumindest für mich. Wenn jemand dies versucht, lass es mich wissen, wie es gelaufen ist.

Tuncay Göncüoğlu
quelle
Ich sollte hinzufügen, dass die Behandlung von SSH-Verbindungen in diesem Zusammenhang ziemlich einfach ist. Lassen Sie unabhängig von der verwendeten Methode keine Root-Anmeldungen über SSH zu, lassen Sie die einzelnen Benutzer mit ihren eigenen Anmeldeinformationen ssh und verarbeiten Sie von dort aus sudo / nosudo / etc.
Tuncay Göncüoğlu