Mehrere Linux-Systemadministratoren arbeiten als Root

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?

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 -

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;

2. 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# 

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.

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.

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.

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.

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.

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;)

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.