Frage Ist die Anmeldung als geteilter Benutzer eine schlechte Angewohnheit?


Ich habe in Organisationen gearbeitet, in denen statt eines neuen Ubuntu-Benutzers pro Person, die sich an einem Computer anmelden möchte, die Systemadministratoren einfach den ssh-Schlüssel jedes Benutzers hinzufügen .ssh/authorized_keys, und alle sshs an die Maschine als (z.B.) ubuntu@host oder ec2-user@host. (Übrigens habe ich gesehen, dass dies in einem Labor auf geteilten Mac-Minis praktiziert wird.) Ist das akzeptierte Praxis oder ein Anti-Pattern?

Die fraglichen Hosts werden hauptsächlich zum Testen verwendet, aber es werden auch Aktionen ausgeführt, die normalerweise eine benutzerspezifische Konfiguration erfordern und von einem bestimmten Benutzer verfolgt werden, z. B. Erstellen und Drücken von Git-Commits, die derzeit mit einem generischen Git ausgeführt werden Nutzer.


35
2018-02-10 19:07


Ursprung


Während viele Menschen Probleme mit poly-amorösen Beziehungen haben, behandeln andere sie einfach gut, also denke ich nicht, dass es notwendigerweise eine "schlechte Angewohnheit" ist, ein ... zu teilen ... oh, vergiss es, du meintest Benutzer Konto. - HopelessN00b
Awww, jemand hat den Clickbait-Titel bearbeitet .. :( - Burgi
@Burgi 10 Gründe, warum ich mich NIEMALS als geteilter Benutzer anmelde! Sie werden Nummer 7 nicht glauben! - user22a6db72d7249


Antworten:


Ja, es ist eine schlechte Angewohnheit. Es beruht auf der Grundannahme, dass niemand boshaft ist (oder sein wird) und niemand Fehler macht. Ein gemeinsamer Account macht es trivial, dass Dinge ohne Verantwortlichkeit und ohne jegliche Begrenzung passieren - ein Benutzer, der etwas kaputt macht, bricht es für alle.

Wenn der Grund für dieses Schema der Benutzerbenutzungsbeschränkung einfach darin besteht, die Verwaltungskosten für die Erstellung neuer Konten und die gemeinsame Nutzung der Konfiguration zu reduzieren, sollten die Administratoren vielleicht etwas Zeit in ein Automatisierungssystem investieren Ansible, Koch, Marionette oder Salz das macht das Erstellen von Benutzerkonten auf mehreren Rechnern extrem einfach.


42
2018-02-10 19:34



Es ist nicht einmal Bosheit, und es ist auch nicht einmal Inkompetenz. Wann etwas Ich arbeite nicht, ich kann nicht davon ausgehen, dass ich mich an alles erinnert hätte, was in diesem Zusammenhang getan wurde. - djechlin
Grundsätze für sichere Daten: Integrität Vertraulichkeit Verfügbarkeit Verantwortlichkeit. +1 für die Verwendung des Wortes accountability - DeveloperWeeks


Das schockiert mich nicht und ich arbeite in einer extrem gesicherten Umgebung. Jeder hat seinen eigenen Benutzer- und Maschinen- und SSH-Schlüssel, und um an einem Server zu arbeiten, schalten wir ihn als root oder als einen anderen Benutzer durch ein Logging-Relay ein, falls nötig. Alles, was wir tun, wird vom Besitzer des SSH-Schlüssels protokolliert, so dass die Verantwortlichkeit in Ordnung ist.

Was wäre die Alternative? Viele Dinge müssen als ein bestimmter Benutzer getan 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.

Aber ich bin mir nicht sicher über deinen letzten Absatz, meinst du, dass jemand einen Git-Commit an einen generischen Benutzer schicken könnte? Das würde die Rechenschaftspflicht brechen, und Rechenschaftspflicht ist schlecht. Wir machen git von der Maschine, wo wir eingeloggt sind und wir authentifizieren uns mit unserem ssh key ...

Authentication, Authorization and Accounting (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, weil Ihr Schlüssel in den authorized_keys ist, und Sie müssen Buchhaltung, was Sie tun kann nach der Tat überprüft werden.


7
2018-02-10 19:47



Ja, der letzte Absatz bedeutet, dass ein Benutzer als generischer Benutzer festlegt. Ich stimme zu, dass es die Rechenschaftspflicht verletzt. Es ist eine bequeme Maßnahme, wenn etwas direkt im Repo auf der Testmaschine repariert werden kann, wird es dort fixiert und dann geschoben. Das ist das Thema, das mich veranlasst hat, diese Frage von Anfang an zu stellen. - user22a6db72d7249
Also hat der generische Benutzer eine Art von Authentifizierung (ssh-Schlüssel?), Die autorisiert ist, den Git-Repo zu modifizieren? Das ist wirklich nicht gut. Nicht nur, weil es die Verantwortung für dieses Commit bricht, sondern auch, weil jede Person diesen Schlüssel kopieren und von woanders verwenden kann. Wenn ich ein solches Problem habe, kopiere ich den Code oder das Diff auf meinen lokalen Rechner und übertrage es von dort aus. - Law29
Warum genau ist nicht sudo akzeptabel für die allgemeine Verwaltung einer Maschine? - Blacklight Shining
Sie ssh als root in "eine extrem sichere Umgebung" oO? - xaa
@xaa Ja, das tue ich, und ich sehe darin kein Problem. Alles, was ich tippe, wird auf anderen Rechnern protokolliert. "Arbeiten Sie nicht als root" ist eine völlig nutzlose Maxime, wenn die Maschine ein Server ist, wo alles, was Sie möglicherweise tun möchten, Sie als Root benötigen. - Law29


Es hängt eindeutig vom Anwendungsfall des Systems ab. Wenn es System zum Testen von Zeit zu Zeit ist, ist es in Ordnung für mich. Wir haben auch solche Systeme. Wenn das Unternehmen über keinerlei Identitätsmanagement (LDAP, IPA) verfügt, ist die Erstellung eines neuen Benutzers ohne Fernsteuerung auf einem beliebigen System eine große Belastung.

Aber für die tägliche Arbeit, wenn ein Fehler die ganze Firma außer Betrieb setzt, ist das keine gute Idee.


3
2018-02-10 22:11



Genau, wenn Sie keinen Verzeichnisdienst haben oder nicht haben können, ist das Erstellen und Verwalten von Tausenden von Konten unpraktisch. - Jim B
Selbst wenn Sie LDAP nicht verwenden können, haben Sie wahrscheinlich immer noch SSH-Zugriff (oder Powershell unter Windows). Sie werden immer noch eine Möglichkeit brauchen, die Datei authorized_keys auf Ihren Hosts für all diese Konten zu verwalten (außer Sie teilen auch Passwörter) und eine Menge anderer Einstellungen. Ich muss mich fragen, warum Sie nicht irgendeine Art von Konfigurations-Management (z. B. Puppet, Chef, Ansible) verwenden Wenn Sie so viele Benutzer oder Server haben. Löst diese Belastung ab und gibt Ihnen im Gegenzug Prozesskontrolle, Rechenschaftspflicht und Überprüfbarkeit. - Martijn Heemels


All diese Antworten beziehen sich auf das Anliegen der Verantwortlichkeit, das an sich ein wichtiges und echtes Problem darstellt, aber die Verwendung eines gemeinsamen Kontos ermöglicht auch nicht so subtile Angriffe auf andere Benutzer:

Stellen Sie sich einen Angreifer vor, der einen Schädling erstellt ssh Skript, das das eingegebene Passwort protokolliert und es in die PATH für diesen freigegebenen Benutzer (was leicht gemacht wird). Jetzt die nächste Person, die sich mit dem geteilten Benutzer bei dieser Maschine anmeldet und entscheidet ssh zu einem anderen Ort (dieses Mal mit seinem persönlichen, ungeteilten Konto) kann eine böse Überraschung haben.

Grundsätzlich ist die Verwendung eines gemeinsamen Kontos auf einem Computer wie das Trinken aus dem Fußbad im öffentlichen Schwimmbad.


3
2018-02-11 23:15





Im Allgemeinen ist die gemeinsame Nutzung eines Kontos aus folgenden Gründen eine schlechte Idee:

  1. Jede Einstellung, die für diesen Benutzer vorgenommen wird, betrifft alle, die sich anmelden. (Promt, Aliase, ...)
    1. Sie verlieren die Möglichkeit, herauszufinden, wer was getan hat (Verantwortlichkeit)
    2. Ein Fehler in der Konfiguration des Accounts (zB versehentliches Löschen des ssh kay) betrifft alle Benutzer, die dieses Benutzerkonto verwenden (in diesem Beispiel sperren).

Und natürlich gibt es noch mehr Nachteile ... Aber ich möchte nicht weiter darauf eingehen.

Der Punkt ist, dass Sie möglicherweise die Notwendigkeit haben, ein Konto zu teilen, um einen Dienst zu verwalten, der unter einem bestimmten Benutzerkonto ausgeführt wird, auf das alle Administratoren zugreifen dürfen.

In einem solchen Setup haben Sie die Möglichkeit, dieses Konto für die Anmeldung freizugeben (für die oben genannten Fälle möchte ich das nicht tun) oder Sie loggen sich einzeln ein und wechseln den Benutzer dann zum gemeinsamen Konto (ich würde das vorschlagen).

Mithilfe von Auditing-Tools können Sie weiterhin nachverfolgen, wer was ausgeführt hat, aber dasselbe Konto weiterhin verwenden.


1
2018-02-12 05:50