Warum TOTP und nicht SMS oder E-Mail
SMS-basierte 2FA lässt sich per SIM-Swapping umgehen, E-Mail-Codes sind nur so sicher wie das E-Mail-Konto selbst. TOTP (Time-based One-Time Password, wie Google Authenticator es implementiert) generiert Codes lokal auf dem Gerät, ganz ohne Netzwerkverbindung — es gibt schlicht keinen Übertragungsweg, den ein Angreifer abfangen könnte.
Google Authenticator PAM installieren
apt install -y libpam-google-authenticator
# Für jeden Benutzer einrichten (als der Benutzer selbst!)
su - admin
google-authenticator
# Fragen beantworten:
# Make tokens time-based? (y) -> TOTP, Standard
# Update .google_authenticator? (y) -> Datei anlegen
# Disallow reuse? (y) -> Replay-Schutz
# Increase 30s window? (n) -> Standard beibehalten
# Enable rate-limiting? (y) -> Brute-Force-Schutz
Trotz des Namens "Google Authenticator" ist das zugrundeliegende TOTP-Protokoll (RFC 6238) offen und herstellerunabhängig — jede TOTP-fähige App funktioniert, nicht nur die von Google. Für Linux-Admins empfehlenswert: Aegis Authenticator (Android, quelloffen, verschlüsseltes Backup) oder Raivo OTP (iOS, ebenfalls quelloffen).
SSH + PAM konfigurieren
# /etc/pam.d/sshd - am Anfang der Datei einfügen
cat > /etc/pam.d/sshd.new << 'EOF'
auth required pam_google_authenticator.so nullok
EOF
cat /etc/pam.d/sshd >> /etc/pam.d/sshd.new
mv /etc/pam.d/sshd.new /etc/pam.d/sshd
# /etc/ssh/sshd_config.d/2fa.conf
cat > /etc/ssh/sshd_config.d/2fa.conf << 'EOF'
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
EOF
systemctl restart sshd
nullok erlaubt Benutzern ohne eingerichtetes TOTP weiterhin den Login (Übergangsphase) — nach der vollständigen Ausrollung sollte nullok entfernt werden, sonst bleibt 2FA für Accounts ohne Setup faktisch optional. AuthenticationMethods publickey,keyboard-interactive erzwingt beide Faktoren (SSH-Key UND TOTP) statt nur eines von beiden.
Testen — unbedingt in einer zweiten Sitzung
Vor dem Neustart von sshd eine zweite SSH-Verbindung offen halten oder Konsolenzugriff sicherstellen. Ein Tippfehler in der PAM-Konfiguration kann sonst jeden SSH-Zugang sperren, inklusive des eigenen.
1. SSH-Key wird akzeptiert
2. Prompt: "Verification code:"
3. TOTP-Code aus App eingeben (6-stellig)
4. Login erfolgreich
Ausnahmen für interne IPs
# /etc/pam.d/sshd - Whitelist für interne IPs
auth [success=1 default=ignore] pam_access.so accessfile=/etc/security/2fa-whitelist.conf
auth required pam_google_authenticator.so nullok
# /etc/security/2fa-whitelist.conf
+ : admin : 192.168.1.0/24
+ : ALL : ALL
Diese Ausnahme ist ein Kompromiss zwischen Sicherheit und Praktikabilität (z.B. für automatisierte Deployment-Skripte aus dem internen Netz) — sie sollte bewusst und dokumentiert gesetzt werden, nicht als bequemer Standard für alle internen IPs.
Recovery-Codes sichern
cat ~/.google_authenticator
# Zeile 1: Secret Key (Base32) — niemals teilen
# Danach: Optionen
# Danach: 5 Scratch-/Recovery-Codes
Die Recovery-Codes gehören in einen Passwort-Manager (z.B. Vaultwarden), nicht in eine Textdatei auf demselben Server, den sie im Notfall absichern sollen — sonst ist der Recovery-Weg im Ernstfall (Server kompromittiert oder unerreichbar) selbst unbrauchbar.
FAQ
Was, wenn ich den TOTP-Code verliere?
Recovery-Codes nutzen. Falls keine vorhanden: physischer Zugang zum Server (Konsole/KVM/IPMI), google_authenticator-Datei löschen und neu einrichten.
Funktioniert das auch mit Hardware-Sicherheitsschlüsseln (YubiKey)?
Für SSH ist FIDO2/U2F über OpenSSHs native sk-ssh-ed25519-Keys oft die bessere Wahl als TOTP-über-PAM — eigenes Thema, technisch aber deutlich phishing-resistenter.
Fazit
TOTP-2FA für SSH ist in wenigen Minuten eingerichtet und schließt eine reale Lücke: Selbst ein gestohlener oder kopierter SSH-Key allein reicht dann nicht mehr für den Login.
Ich richte 2FA und weitere Härtungsmaßnahmen für Linux-Server bei Unternehmen in Heidelberg und der Rhein-Neckar-Region ein. Kontakt aufnehmen.