SSH auf CentOS 7 mit WiKID Zwei-Faktor-Authentifizierung sichern

Ziel und Varianten
Primäre Absicht: SSH mit WiKID 2FA absichern. Verwandte Varianten: SSH Zwei‑Faktor‑Authentifizierung, pam_radius auf CentOS 7, WiKID RADIUS Integration, SSH 2FA Anleitung.
Warum Zwei‑Faktor für SSH?
SSH ist technisch sehr sicher, aber Audits (z. B. PCI) oder interne Compliance‑Vorgaben verlangen oft stärkere Kontrollen, die SSH allein nicht bietet:
- Keine zentrale Kontrolle, welche Nutzer Public‑Key‑Autorisierung nutzen.
- Keine Durchsetzung von Passphrasenkomplexität für Schlüssel.
- Keine eingebaute Ablaufsteuerung für Public Keys.
Zwei‑Faktor‑Authentifizierung (2FA) kombiniert etwas, das der Nutzer besitzt (WiKID‑Token) mit etwas, das er weiß (PIN). Das erhöht Sicherheit und Auditierbarkeit.
Voraussetzungen
- Ein laufender CentOS 7 Server mit Root‑Zugriff.
- Ein erreichbarer WiKID‑Server (oder ein Zwischen‑RADIUS), erreichbar vom Zielserver.
- Paketwerkzeuge: wget, tar, make, gcc und sudo privileges.
- Optional: LDAP/AD für zentrale Benutzerverwaltung.
Wichtig: Bevor Sie Änderungen an SSH/PAM vornehmen, haben Sie eine alternative Konsolenzugriffsmöglichkeit (KVM, Konsole des Cloud‑Providers oder eine Notfall‑Bastion), falls die Authentifizierung fehlschlägt.
Domain auf dem WiKID Server hinzufügen
Hinweis: Der Domain Server Code ist die nullgefüllte externe IP Ihres Servers. Beispiel: IP 54.83.0.181 → Servercode 054083000181. Verwenden Sie genau dieses Format als Domain Identifier.
Netzwerk‑Client erstellen
Nach dem Speichern der Domain wechseln Sie auf den Tab Netzwerk‑Client und wählen Create New Network Client. Tragen Sie einen aussagekräftigen Namen und die IP‑Adresse des SSH‑Gateways (oder des Servers) ein. Wählen Sie als Protokoll RADIUS und die zuvor erstellte Domain.
Klicken Sie auf Add und geben Sie auf der Folgeseite das Shared Secret für RADIUS ein.
Wiederholen Sie diesen Schritt für jeden Server, der die WiKID‑Authentifizierung nutzen soll.
SSH auf dem CentOS 7 Server konfigurieren
Dieses Kapitel beschreibt die Installation und Konfiguration von pam_radius auf RedHat/CentOS 7.
- Quelle herunterladen. Aktuelle Version im Beispiel: 1.3.17
$ wget ftp://ftp.freeradius.org/pub/radius/pam_radius-1.3.17.tar.gz
- Archiv entpacken
$ tar -xzvf pam_radius-1.3.17.tar.gz
- Abhängigkeiten installieren
$ sudo yum install pam-devel
- In das Verzeichnis wechseln und kompilieren
$ make
Hinweis: Make kann Warnungen ausgeben. Entscheidend ist, dass die Bibliothek pam_radius_auth.so erzeugt wird.
- Bibliothek an den richtigen Ort kopieren (32‑bit / 64‑bit)
$ sudo cp pam_radius_auth.so /lib/security/
oder
$ sudo cp pam_radius_auth.so /usr/lib64/security/
- SSH (PAM) anweisen, RADIUS zu verwenden. Öffnen Sie die PAM‑Konfigurationsdatei für SSH, typischerweise /etc/pam.d/sshd, oder fügen Sie in der SSH‑PAM‑Kette die folgende Zeile hinzu (als zweite auth‑Zeile):
auth sufficient /lib/security/pam_radius_auth.so
Erläuterung: ‘sufficient’ lässt die Authentifizierung bei erfolgreichem RADIUS passieren, erlaubt aber weiterhin lokale Passwörter als Fallback. Ersetzen Sie ‘sufficient’ durch ‘required’, wenn RADIUS zwingend sein soll — nur wechseln, wenn Sie die Funktionalität getestet haben.
RADIUS‑Server in PAM konfigurieren
Sie müssen PAM mitteilen, wo sich der WiKID‑RADIUS‑Server befindet und welches Shared Secret verwendet wird. Die Konfigurationsdatei heißt in vielen Distributionen /etc/pam_radius_auth.conf.
Beispielzeile in /etc/pam_radius_auth.conf:
other-server other-secret 3
Ersetzen Sie ‘other-server’ durch die IP‑Adresse oder den Hostnamen Ihres WiKID Servers (oder eines Zwischen‑RADIUS) und ‘other-secret’ durch das Shared Secret, das Sie beim Anlegen des Netzwerkclients in WiKID gesetzt haben. Die letzte Zahl ist das Timeout/Versuchslimit in Sekunden/Anfragen (je nach Implementierung).
Starten Sie sshd nicht sofort neu; testen Sie zuerst Verbindungen in einer separaten Session und prüfen Sie das Log.
Testen und Troubleshooting
- Überwachen Sie die Logs live:
$ sudo tail -f /var/log/secure
- Testen Sie von einem anderen Host per SSH. Lassen Sie die aktuelle Sitzung offen, bis der Test erfolgreich ist.
- Wenn die RADIUS‑Anfrage nicht ankommt, prüfen Sie Firewalls und SELinux (temporär SELinux im Permissive‑Modus testen).
- Bei falschem Shared Secret sehen Sie Authentication‑Failures im WiKID‑Server‑Log.
Wichtig: Solange Sie die lokale Accountverwaltung nicht verändert haben, benötigt der Benutzer weiterhin ein lokales Konto (oder Sie koppeln PAM an pam_ldap/pam_sss für zentrale Accounts).
Feingranulare Kontrolle und Root‑Zugriff
Sie können WiKID‑OTP für root‑Zugriff erfordern, indem Sie für su/sudo eine eigene WiKID‑Domain anlegen und /etc/pam.d/su entsprechend anpassen. Das erlaubt, Server in Gruppen zu verwalten und unterschiedliche Admin‑Domänen zu verwenden (z. B. HR‑Server mit gesonderten Admins).
Alternative Ansätze
- Duo Security, Google Authenticator PAM‑Module, FreeRADIUS + TOTP sind mögliche Alternativen zu WiKID.
- Vorteil von RADIUS‑basierten Lösungen: zentrale Prüfung der PIN/OTP und die Möglichkeit, Autorisierung via LDAP/AD zu routen.
Wann diese Lösung nicht geeignet ist
- Kein Netzwerkzugang zum WiKID‑Server (RADIUS) → kein Login möglich.
- Wenn Nutzer kein Token haben oder Token nicht verteilt werden können.
- Strikte Offline‑Umgebungen ohne RADIUS‑Konnektivität.
Sicherheits‑Härtungsempfehlungen
- Nach erfolgreichem Test: Setzen Sie in /etc/ssh/sshd_config PasswordAuthentication no, falls Sie ausschließlich RADIUS/Tokens verwenden möchten.
- Nutzen Sie Fail2ban oder ähnliche Schutzmechanismen, um Bruteforce‑Versuche auf SSH zu begrenzen.
- Schützen Sie das Shared Secret zwischen Client und WiKID und wechseln Sie es bei Verdacht auf Kompromittierung.
- Beschränken Sie RADIUS‑Zugriff per IP‑Filter auf bekannte Server.
Datenschutz und Compliance Hinweise
- Da Authentifizierungsdaten über das Netzwerk gehen, dokumentieren Sie, welche Daten an WiKID übertragen werden. Prüfen Sie, ob personenbezogene Daten betroffen sind und wie lange Logs gespeichert werden.
- Für GDPR/DSGVO: Minimieren Sie personenbezogene Daten in Logs und stellen Sie Lösch‑/Deaktivierungsprozesse für Nutzer sicher.
Playbook: Schritt‑für‑Schritt für die Einführung (Kurzfassung)
- Backup und alternative Konsole bereitstellen.
- WiKID Domain anlegen; Servercode korrekt nullgefüllt setzen.
- Netzwerk‑Client für jeden Server anlegen; Shared Secret notieren.
- pam_radius kompilieren und .so an den richtigen Ort kopieren.
- /etc/pam_radius_auth.conf mit WiKID‑IP und Shared Secret befüllen.
- /etc/pam.d/sshd anpassen: auth sufficient /lib/security/pam_radius_auth.so.
- In einer separaten Session testen; Logs überwachen.
- Nach erfolgreichem Test PasswordAuthentication abschalten und weitere Härtungen vornehmen.
- Dokumentation und Rollback‑Plan erstellen.
Rollenbasierte Checklisten
Administrator:
- Backup der SSH/PAM Konfiguration anlegen.
- WiKID‑Domain und Clients konfigurieren.
- PAM/sshd anpassen und Tests durchführen.
Sicherheitsbeauftragter:
- Shared Secrets prüfen und Rotation planen.
- Zugriffskontrollen und Log‑Retention prüfen.
Auditor:
- Nachweis führen, dass 2FA für Remote‑Zugriff aktiv ist.
- Protokolle einsehen (Loginversuche, Deaktivierungen).
Mental Model: Warum das funktioniert
2FA = Besitz (Token/Device) + Wissen (PIN). RADIUS ermöglicht zentrale Validierung und einfache Deaktivierung von Tokens ohne lokale Accountänderung.
Glossar (Einzeiler)
- PAM: Pluggable Authentication Modules, modulare Authentifizierungsarchitektur für Linux.
- RADIUS: Remote Authentication Dial‑In User Service, Protokoll zur zentralen Authentifizierung.
- WiKID: Zwei‑Faktor‑Authentifizierungsserver/Anbieter, der RADIUS unterstützen kann.
- OTP: One‑Time Passcode, einmalig verwendbares Einmalpasswort.
Quellen und Links
- CentOS: http://www.centos.org
- PAM RADIUS: http://freeradius.org/pam_radius_auth/
- WiKID Two‑factor authentication: https://www.wikidsystems.com
Zusammenfassung
- WiKID plus pam_radius erlaubt eine zentrale, auditierbare Zwei‑Faktor‑Authentifizierung für SSH auf CentOS 7.
- Legen Sie Domains und Netzwerk‑Clients im WiKID an, konfigurieren Sie pam_radius lokal und testen Sie umfangreich.
- Bewahren Sie Fallback‑Zugänge und einen Rollback‑Plan auf, bevor Sie PasswordAuthentication abschalten.
Wichtig: Testen Sie jede Änderung in einer dedizierten Wartungs‑ oder Testumgebung, bevor Sie sie in Produktion übernehmen. Bei Problemen nutzen Sie die Notfallkonsole, um Sperrungen zu vermeiden.
Ähnliche Materialien

Linux auf Chromebook installieren

smartmontools: Festplatten überwachen & einrichten
Logjam-Schutz für Debian/Ubuntu-Server

Dark Sky: Hyperlokale Regenvorhersage & Alternativen

SSH auf CentOS 7 mit WiKID 2FA sichern
