====== SSH - PKI und Principals ======
Sicherheit kostet immer Ressourcen, seinen es Aufwände oder Kosten. Darüber hinaus werden Sicherheitsmaßnahmen nur dann wirklich akzeptiert, wenn sie ohne großen Aufwand, gerade in der täglichen Arbeit, umgesetzt werden.\\
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 [[.: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.\\
Kommt nur ein Benutzer hinzu, den der Anwender benötigt, muss der Key neu signiert werden. Gerade in Development Teams führt dies zu unnötigem Aufwand, denn es ist ja nicht nur ein Key neu zu signieren sondern die Keys aller Mitglieder eines Teams benötigen eine neue Signatur.\\
OpenSSH bietet die Möglichkeit verschiedene Benutzer auf dem Server zu Grupoen (sogenannte Principals) zusammenzufassen. Ordnet man der Devlopern also nicht eine Liste von Benutzern zu, sondern einen (oder mehrere) Principals (Gruppen), braucht man nur auf dem SSH Server die Definition dieser Gruppe anzupassen und die erneutet Signatur aller Keys, deren Zugriff geändert wird, entfällt. 
===== Die Umsetzung =====
Die erforderlichen Änderungen, Principals nicht mehr als Benutzernamen sondern als Gruppe aufzufassen, erfolgt nur auf dem SSH-Server.\\
Betrachten wir die Möglichkeiten, die zur Verfügung stehen. In einer Konfigurationsdatei (pro Benutzer) wird hinterlegt, welche Principals die Berechtigung haben, sich als ein bestimmter Benutzer anzumelden. Enthält die Signatur einen der erforderlichen Principals, ist eine Anmeldung erlaubt.\\
|  **Beachten Sie: Diese Möglichkeiten bieten sich nur, wenn signierte Public Keys zum Einsatz kommen** |\\ 
Die angesprochene Konfigurationsdateien bestehen aus je einer Zeile für jeden Principal, der Zugriff auf den Benutzer erhalten soll.
Hier ein Beispiel für den Zugriff auf den User "mysql" für die Principals "dba" und "developer":
  dba
  developer
Da "mysql" in der Liste der Principals nicht vorkommt ist auch die Anmeldung nicht möglich wenn die Signatur explizit den User mysql als Principal ausweist. Soll auch die Anmeldung durch den Principal "mysql" möglich sein, muss dies in der Liste vermerkt sein. Das Ganze sieht dann so aus:
  mysql
  dba
  developer
Die Anzahl der Konfiguraitonsdateien kann, je nach Erfordernissen, groß werden. Benutzen wir Principals (anstelle von Benutzernamen) bei der Signatur, muss für jeden einzelnen der Benutzer eine solche Datei existieren. Die Möglichkeiten die Namen der Konfigurationsdateien zu bestimmen sidn beschränkt. Als Variablen sind hier die Folgenden möglich:
  AuthorizedPrincipalsFile accepts the tokens %%, %h, %U, and %u.
    %%    A literal ‘%’.
    %h    The home directory of the user.
    %U    The numeric user ID of the target user.
    %u    The username.
 Um eine ausufernde Anzahl von Konfigurationsdateien zu vermeiden bietet OpenSSH freundlicherweise auch die Möglichkeit, die Konfiguration durch ein Programm oder Skript dynamisch zu ermitteln. Meine Lösung sieht die Nutzung eines solchen Skripts vor, das mit einer einzigen Konfigurationsdatei auskommt.
===== Vorbereitung des SSH Servers =====
Für die Umsetzung müssen folgende Einträge in der sshd_config gemacht werden:
  # 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
  #   Der erste Parameter für das Skript ist der Name der Konfiguationsdatei.
  #   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. 
  #   useradd -r principals -c "Check ssh prinipals" -d /home/principals -G root
  #   Die Ausführung als root birgt Sicherheisrisiken. 
  #   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