In meinem Unternehmen verwenden wir LDAP, um auf allen Computern einen einheitlichen Kontensatz zu haben, und verwenden dann ein Konfigurationsverwaltungstool (in unserem Fall derzeit cfengine), um authorized_keysDateien für jeden Benutzer auf allen Servern zu verteilen . Die Schlüsseldateien selbst werden (zusammen mit anderen Systemkonfigurationsinformationen) in einem Git-Repository gespeichert, damit wir sehen können, wann Schlüssel kommen und gehen. cfengine verteilt auch eine sudoersDatei, die steuert, wer Zugriff hat, um was als root auf jedem Host auszuführen, und zwar unter Verwendung der Benutzer und Gruppen aus dem LDAP-Verzeichnis.
Die Kennwortauthentifizierung ist auf unseren Produktionsservern vollständig deaktiviert, daher ist die SSH-Schlüsselauthentifizierung obligatorisch. Die Richtlinie empfiehlt die Verwendung eines separaten Schlüssels für jeden Laptop / Desktop / was auch immer und die Verwendung einer Passphrase für alle Schlüssel, um die Auswirkungen eines verlorenen / gestohlenen Laptops zu verringern.
Wir haben auch einen Bastion-Host, der verwendet wird, um auf Hosts im Produktionsnetzwerk zuzugreifen, sodass wir in diesem Netzwerk sehr restriktive Firewall-Regeln haben. Die meisten Ingenieure haben eine spezielle SSH-Konfiguration, um dies transparent zu machen:
Host prod-*.example.com
User jsmith
ForwardAgent yes
ProxyCommand ssh -q bastion.example.com "nc %h %p"
Das Hinzufügen eines neuen Schlüssels oder das Entfernen eines alten Schlüssels erfordert in diesem Setup einige Zeremonien. Ich würde argumentieren, dass es für das Hinzufügen eines neuen Schlüssels wünschenswert ist, dass es sich um eine Operation handelt, die einen Prüfpfad verlässt und für alle sichtbar ist. Aufgrund des damit verbundenen Aufwands wird es jedoch manchmal vernachlässigt, einen alten Schlüssel zu entfernen, wenn er nicht mehr benötigt wird, und wir haben keine echte Möglichkeit, dies zu verfolgen, außer aufzuräumen, wenn ein Mitarbeiter das Unternehmen verlässt. Es erzeugt auch zusätzliche Reibung, wenn ein neuer Ingenieur an Bord ist, da er einen neuen Schlüssel generieren und an alle Hosts senden muss, bevor er vollständig produktiv ist.
Der größte Vorteil ist jedoch, dass jeder Benutzer einen eigenen Benutzernamen hat. Dies erleichtert die differenziertere Zugriffskontrolle, wenn dies erforderlich ist, und gibt jedem Benutzer eine Identität, die in Überwachungsprotokollen angezeigt wird Produktionsproblem zurück zu einer Sysadmin-Aktion.
Bei dieser Konfiguration ist es lästig, automatisierte Systeme zu haben, die Maßnahmen gegen Produktionshosts ergreifen, da deren "bekannte" SSH-Schlüssel als alternativer Zugriffspfad dienen können. Bisher haben wir den Benutzerkonten für diese automatisierten Systeme nur den minimalen Zugriff gewährt, den sie für ihre Arbeit benötigen, und akzeptiert, dass ein böswilliger Benutzer (der bereits Ingenieur mit Produktionszugriff sein muss) diese Aktionen auch halbwegs ausführen kann. anonym mit dem Schlüssel der Anwendung.