Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- howtos:sshprincipals [2023/07/21 11:15] – [Die Umsetzung] morquai
+++ howtos:sshprincipals [2023/07/26 10:11] (aktuell) – [Die Idee] morquai
@@ Zeile 3: / Zeile 3: @@
 Die Verteilung von Public Keys auf die entsprechenden Server oder die Notwendigkeit der erneuten Signatur wenn sich an der Liste der erlaubten User etwas ändert, stellen Hindernisse dar, die beim Benutzer Unmut auslösen können. Wie hier Abhilfe geschaffen wird, zeige ich Ihnen im Folgenden.\\
 ===== Die Idee =====
-Im How-to [[.:howtos:sshexpert|SSH - für Fortgeschrittene]] haben wir den Public Key mit folgendem Befehl signiert:\\
+Im How-to [[.:sshexpert|SSH - für Fortgeschrittene]] haben wir den Public Key mit folgendem Befehl signiert:\\
   ssh-keygen -s id_rsa_userca -I "vorname.machname@example.com" -n "unixuser1,unixuser2" -V +2w -z 1 id_rsa.pub
 Mit "-n" haben wir festgelegt, dass die Signatur für die Benutzer unixuser1 und unixuser2 auf dem Server Gültigkeit besitzt.\\
@@ Zeile 31: / Zeile 31: @@
   # Liste der erlaubten Certification Authorities
   TrustedUserCAKeys /etc/ssh/TrustedUserCAKeys
   # Datei, die zurückgezogene Keys enthält
   RevokedKeys /etc/ssh/revoked-keys
   # Name der zentralen Konfigurationsdatei. "none" ist der Default und bedeutet,
   #   dass keine solche existiert
   AuthorizedPrincipalsFile none
   # Name und Parameter des Skripts, dass die Konfiguration dynamisch ermittelt
   #   Es müssen absolute Pfadangaben benutzt werden
@@ Zeile 41: / Zeile 44: @@
   #   Der zweite Parameter ist der Name des Benutzers, der sich anmelden will
   AuthorizedPrincipalsCommand /etc/ssh/AuthorizedPrincipalsCommand.sh /etc/ssh/AuthorizedPrincipalsFile %u
   # Hier wird der Benutzer definiert, unter dessen ID das Skript ausgeführt wird. Es wird
   #   empfohlen für diesen Zweck einen eigenen Benutzer anzulegen.
@@ Zeile 47: / Zeile 51: @@
   #   Der Benutzer muss Leserechte für die Konfigurationsdatei besitzen
   AuthorizedPrincipalsCommandUser principals
+Die Konfigurationsdatei enthält Zeilen mit je zwei Spalten, Spalte 1 entspricht dem User Namen, alles ab Spalte zwei definiert, durch Kommata getrennt, die zuässigen Principals. Bei den Namen der Principals dürfen aus diesen Grund keine Kommata benutzt werden!\\
+Weiter unten werde ich an ein Beispiel einer solchen Konfigurationsdatei vorstellen.
+Das Skript leistet folgendes: Es ermittelt aus allen Zeilen, deren erste Spalte gleich dem Benutzernamen ist, die Principals. Mehrere Zeilen mit gleichem Benutzernamen werden additiv aufgefasst, doppelte Principals für einen Benutzer werden entfernt. Der Code ist wie folgt:
+  #!/bin/bash
+  # echo $0 Invoked with "$*" as parameter >/tmp/AuthorizedPrincipalsCommand.log
+  awk -v user="$2" '\
+     BEGIN\
+        {\
+           printed=0\
+        }\
+     $1==user\
+        {\
+          # remember user was found and print $0 starting at $2 \
+          printf "%s",","substr($0,index($0,$2)) ; printed=1 \
+        }\
+     END\
+        {\
+          # if the user was found allow the user to be a valid principal \
+          if(printed==1){print ","user}\
+        }' "$1" 2>/dev/null \
+     | sed 's/^,//;s/,/\n/g;s/^[[:space:]]*//' \
+     | sort -u
+Damit diese Einstellungen wirksam werden, muss der SSH Server neu gestartet werden. Die angegebenen Dateien und Benutzer müssen existieren.\\ \\
+Sehen wir uns nun ein Beispiel an. Wir haben zwei Development Teams, dev1 und dev2. \\
+Beide Teams sollen Zugriff
+|auf den User mysql  |\\
+|dev1 zusätzlich zum User app1  |\\
+|dev2 zusätzlich zum User app2  |\\
+|das DBA Team benötigt ebenfalls Zugriff auf den User mysql  |\\
+|Weiterhin benötigen wir in der Liste alle Developer selbst, ihre Benutzernamen lauten user1, user2, user3 und user4.|\\
+Die Konfigurationsdatei /etc/ssh/AuthorizedPrincipalsFile sieht dann folgendermaßen aus:\\
+  # user          principals (comma separated)
+  #                  duplicate user entries will be combined,
+  #                  duplicate principals will be used only once
+  #                  user name will be added as separate principal
+  #--------------!-------------------
+    app1          dev1
+    app2          dev2
+    mysql         dev1,dev2
+    mysql         dba
+    user1
+    user2
+    user3
+    user4
+Testen wir nun das Skript\\
+  sudo -u principals /etc/ssh/AuthorizedPrincipalsCommand.sh /etc/ssh/AuthorizedPrincipalsFile mysql
+    dba
+    dev1
+    dev2
+    mysql
+  sudo -i principals /etc/ssh/AuthorizedPrincipalsCommand.sh /etc/ssh/AuthorizedPrincipalsFile app1
+    app1
+    dev1
+  sudo -i principals /etc/ssh/AuthorizedPrincipalsCommand.sh /etc/ssh/AuthorizedPrincipalsFile app2
+    app2
+    dev2
+  sudo -i principals /etc/ssh/AuthorizedPrincipalsCommand.sh /etc/ssh/AuthorizedPrincipalsFile user3
+    user3
+Voila, eine Konfigurationsdatei löst das Problem erneut signieren zu müssen, falls Teams Zugriff auf weitere Benutzer benötigen. Nehmen wir an, "user3" gehört zu, Team "dev2". Der Public Key ist dann folgendermaßen zu signieren um ihm Zugriff auf die User mysql,app2 und user3 zu erteilen:
+  ssh-keygen -s id_rsa_userca -I "vorname.machname@example.com" -n "user3,dev2" -V +2w -z 1 id_rsa.pub

OnkelHartwig

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge