Werbung
Sobald schlüsselbasiertes SSH eingerichtet ist, folgt meist direkt die Empfehlung für Zwei-Faktor-Authentifizierung (2FA): Das Anfordern eines TOTP-Codes aus einer Authenticator-App zusätzlich zum privaten Schlüssel. Es wird als der logische nächste Schritt präsentiert. Mehr Faktoren bedeuten mehr Sicherheit. Das stimmt zwar, aber wir müssen sehr genau sein, gegen welche spezifische Bedrohung dies eigentlich schützt. Denn nur so lässt sich entscheiden, wo der zusätzliche Aufwand gerechtfertigt ist und wo nicht.
Wovor es tatsächlich schützt
Key-Only-SSH stellt bereits sicher, dass niemand mit einem erratenen, geleakten oder gephishten Passwort auf den Server kommt. Es gibt schlichtweg kein Passwort, das man stehlen könnte. SSH 2FA schützt spezifisch vor der Kompromittierung des privaten Schlüssels selbst: gestohlen von einem Laptop, kopiert aus einem unverschlüsselten Backup oder entwendet von einer anderweitig kompromittierten Maschine. Passiert das, reicht der Schlüssel allein nicht mehr aus; der Angreifer benötigt auch noch den TOTP-Code auf Ihrem Smartphone.
Laptops werden gestohlen. Backups werden falsch konfiguriert. Das Argument „Der Key liegt auf einer verschlüsselten Festplatte“ zieht nur, wenn die Festplatte tatsächlich verschlüsselt war und der Laptop zum Zeitpunkt des Diebstahls gesperrt war. Es ist also ein reales Szenario. Aber es ist ein sehr spezifisches Szenario und kein allgemeiner Fix für „SSH-Sicherheit“. Die generelle Bedrohungslage wird durch schlüsselbasierte Authentifizierung bereits hervorragend abgedeckt.
Das Setup
Der Standardweg, um TOTP zu SSH unter Linux hinzuzufügen, ist pam_google_authenticator:
apt install libpam-google-authenticator
google-authenticator
Das Tool generiert ein Secret (sowie einen QR-Code) und Backup-Codes. Danach muss man PAM und SSH anweisen, diesen Code zwingend anzufordern:
# /etc/pam.d/sshd
auth required pam_google_authenticator.so
# /etc/ssh/sshd_config
AuthenticationMethods publickey,keyboard-interactive
KbdInteractiveAuthentication yes
Die Zeile AuthenticationMethods publickey,keyboard-interactive ist hierbei der kritische Punkt. Sie erzwingt, dass sowohl der Key als auch der TOTP-Prompt erfolgreich durchlaufen werden müssen. Macht man hier einen Fehler (z.B. indem man den Eintrag weglässt), akzeptiert der Server möglicherweise nur einen der beiden Faktoren, was die gesamte Maßnahme ad absurdum führt. Testen Sie das Setup daher immer zwingend in einem zweiten Terminalfenster, bevor Sie Ihre aktuelle Sitzung schließen.
Wo 2FA zum Problem wird
Die zusätzliche Reibung durch 2FA macht sich an zwei Stellen bemerkbar. Erstens bei menschlichen Logins. Für jede interaktive SSH-Sitzung brauchen Sie ab sofort Ihr Smartphone. Das nervt, wenn man sich dutzende Male am Tag einloggt, ist aber handhabbar.
Zweitens – und das ist weitaus kritischer – es bricht Automatisierungen. Eine CI/CD-Pipeline, die per SSH deployt, ein Ansible-Playbook oder ein Cronjob, der via rsync Backups auf einen Remote-Host schiebt: Keiner dieser Prozesse hat einen Menschen vor dem Bildschirm sitzen, der mal eben einen 6-stelligen Code eintippen könnte. Eine serverweite Durchsetzung von AuthenticationMethods publickey,keyboard-interactive macht all diese Automatisierungen augenblicklich kaputt. Und meistens merkt man das erst, wenn der nächste geplante Job lautlos fehlschlägt.
Der richtige Mittelweg
Anstatt 2FA blind überall zu erzwingen, sollte es nur für interaktive Logins von Menschen gelten. Automatisierungen sollten separate, eingeschränkte Service-Accounts nutzen, die die 2FA-Anforderung umgehen. Solche Accounts müssen ohnehin anderweitig eingeschränkt werden, beispielsweise durch ein forced command in der authorized_keys oder indem der Key nur für ein bestimmtes Skript freigeschaltet ist.
# /etc/ssh/sshd_config
Match User deploy,admin
AuthenticationMethods publickey,keyboard-interactive
Match User ci-deploy
AuthenticationMethods publickey
So erhalten menschliche Accounts, die beliebige Befehle ausführen dürfen, den zusätzlichen Sicherheitsfaktor. Gleichzeitig laufen streng limitierte Automatisierungs-Accounts – die ohnehin keinen TOTP-Code liefern könnten und deren Keys sicher in CI-Secrets und nicht auf Laptops liegen – reibungslos weiter.
Mein Fazit
Wenn auf einen Server ausschließlich Maschinen und Skripte zugreifen und es keine menschlichen interaktiven Logins gibt, bringt SSH 2FA keinen nennenswerten Mehrwert. Das entsprechende Bedrohungsmodell (ein gestohlener Entwickler-Key) greift hier schlichtweg nicht.
Für Server, auf denen sich jedoch tatsächlich Menschen einloggen und Befehle ausführen – insbesondere Produktionsumgebungen mit Echtdaten – ist das Laptop-Diebstahl-Szenario real. Die geringfügige Hürde eines TOTP-Prompts ist den Aufwand absolut wert, solange das Setup sauber mit Match User eingegrenzt wird, damit die Automatisierung, die den Betrieb am Laufen hält, nicht ungewollt lahmgelegt wird.
Werbung