Ist es eine schlechte Angewohnheit, sich als gemeinsamer Benutzer anzumelden?

Ich habe in Organisationen gearbeitet, in denen anstatt eines neuen Ubuntu-Benutzers pro Person, der sich auf einem Computer anmelden möchte, die Sysadmins einfach den SSH-Schlüssel jedes Benutzers .ssh/authorized_keysund alle Benutzer sshauf dem Computer als ( z . B. ) ubuntu@hostoder hinzufügen ec2-user@host. (Übrigens habe ich dies auch auf gemeinsam genutzten Mac-Minis in einer Laborumgebung üben sehen.) Ist dies akzeptierte Praxis oder ein Anti-Pattern?

Die fraglichen Hosts werden hauptsächlich zu Testzwecken verwendet, es werden jedoch auch Aktionen ausgeführt, die in der Regel eine Benutzerkonfiguration erfordern und von einem bestimmten Benutzer ausgeführt werden, z. B. das Erstellen und Übertragen von Git-Commits, die derzeit mit einem generischen Git ausgeführt werden Benutzer.

Ja, es ist eine schlechte Angewohnheit. Es basiert auf der Grundannahme, dass niemand bösartig ist (oder sein wird) und dass niemand Fehler macht. Wenn Sie ein gemeinsames Konto haben, ist es trivial, dass Dinge ohne Rechenschaftspflicht und unbegrenzt passieren - ein Benutzer, der etwas bricht, bricht es für alle.

Wenn der Grund für dieses UID-Freigabeschema lediglich darin besteht, die Verwaltungskosten für die Erstellung neuer Konten und die Konfiguration der Freigabe zu senken, sollten die Administratoren möglicherweise etwas Zeit in ein Automatisierungssystem wie Ansible , Chef , Puppet oder Salt investieren , mit dem beispielsweise Benutzer erstellt werden Konten auf mehreren Rechnern extrem einfach.

Zunächst schockiert mich das nicht und ich arbeite in einer extrem sicheren Umgebung. Jeder hat seinen eigenen Benutzer und seinen eigenen Computer und SSH-Schlüssel, und für die Arbeit auf einem Server, den wir als Root oder als anderer Benutzer verwenden, verwenden wir bei Bedarf ein Logging-Relay. Alles, was wir tun, wird vom Eigentümer des SSH-Schlüssels als erledigt protokolliert, sodass die Verantwortlichkeit in Ordnung ist.

Was wäre die Alternative? Viele Dinge müssen als bestimmter Benutzer erledigt werden, ganz zu schweigen von root. Sudo? Das ist in Ordnung für bestimmte sehr eingeschränkte Aufgaben, aber nicht für die Systemadministration der Maschine.

Allerdings bin ich mir bei deinem letzten Absatz nicht sicher. Meinst du, dass jemand einen git-Commit an einen generischen Benutzer senden könnte? Das würde die Rechenschaftspflicht brechen, und die Rechenschaftspflicht zu brechen ist schlecht. Wir tun Git von der Maschine, auf der wir angemeldet sind und authentifizieren uns mit unserem SSH-Schlüssel ...

Authentifizierung, Autorisierung und Kontoführung (AAA) ist der klassische Ausdruck: Sie sind mit Ihrem SSH-Schlüssel authentifiziert, Sie sind berechtigt, alles zu tun, was der generische Benutzer tun kann, da sich Ihr Schlüssel in den authorized_keys befindet, und Sie müssen die Kontoführung durchführen, damit Sie das tun kann nachträglich überprüft werden.

Dies hängt eindeutig vom Anwendungsfall des Systems ab. Wenn es ein System zum Testen von Zeit zu Zeit ist, ist es in Ordnung für mich. Wir haben auch solche Systeme. Wenn das Unternehmen nicht über ein Identitätsmanagement (LDAP, IPA) verfügt, ist das Erstellen eines neuen Benutzers ohne Remote-Kontrolle über ein zufälliges System eine ziemliche Belastung.

Aber für die tägliche Arbeit ist es keine gute Idee, wenn ein Fehler das gesamte Unternehmen funktionsunfähig macht.

Alle diese Antworten befassen sich mit dem Problem der Rechenschaftspflicht, das für sich genommen ein wichtiges und reales Problem darstellt. Die Verwendung eines gemeinsam genutzten Kontos ermöglicht jedoch auch nicht so subtile Angriffe auf andere Benutzer:

Stellen Sie sich einen Angreifer vor, der ein böswilliges sshSkript erstellt, das das eingegebene Kennwort protokolliert und es PATHfür diesen freigegebenen Benutzer einfügt (was leicht zu tun ist). Jetzt kann die nächste Person, die sich mit dem freigegebenen Benutzer auf diesem Computer anmeldet und sich sshfür einen anderen Ort entscheidet (diesmal mit seinem persönlichen, nicht freigegebenen Konto), eine böse Überraschung erleben.

Grundsätzlich ist das Verwenden eines gemeinsam genutzten Kontos an einem Computer wie das Trinken aus dem Fußbad im öffentlichen Schwimmbad.

Im Allgemeinen ist das Teilen eines Kontos aus den folgenden Gründen eine schlechte Idee:

1. Jede Einstellung, die für diesen Benutzer vorgenommen wird, wirkt sich auf alle Benutzer aus, die sich anmelden. (Eingabeaufforderung, Aliase, ...)
   2. Sie verlieren die Möglichkeit herauszufinden, wer was getan hat (Verantwortlichkeit)
   3. Ein Fehler in der Konfiguration des Kontos (beispielsweise das versehentliche Löschen des ssh kay) betrifft alle Benutzer, die dieses Benutzerkonto verwenden (in diesem Beispiel das Sperren).

Und mit Sicherheit gibt es noch mehr Nachteile ... Aber ich möchte nicht weiter darauf eingehen.

Möglicherweise müssen Sie ein Konto freigeben, um einen Dienst zu verwalten, der unter einem bestimmten Benutzerkonto ausgeführt wird, auf das alle Administratoren zugreifen können sollen.

In einem solchen Setup haben Sie die Möglichkeit, dieses Konto für die Anmeldung freizugeben (aus den obigen Gründen würde ich dies lieber nicht tun) oder Sie melden sich einzeln an und wechseln den Benutzer dann auf das freigegebene Konto (das würde ich vorschlagen).

Mit den Überwachungstools können Sie weiterhin nachverfolgen, wer was ausgeführt hat, aber immer noch dasselbe Konto verwendet.