Wer von unterwegs gern mal digital zu Hause oder auf der Arbeit vorbei schaut, der hat immer wieder ein sehr sehr ungutes Gefühl, wenn sich auch andere Menschen über das Internet auch nur theoretisch dorthin verbinden könnten...aber eben auch nicht das das beste Schloss an der Haustür.
Wie konfiguriere ich also Google Authenticator zum Sprung auf eine Bastion?
- Anlegen einer mobilen Benutzergruppe und des Beispiel-Benutzers "Hans" auf dem Zielsystem
- Daher wir mit Hans noch böse Dinge vor haben, bekommt dieser Sonderrechte.
- Generieren eines Schlüssels auf der Quellmaschine und verbinden an das Ziel.
- Auf der Zielmaschine zum Root werden und nun die fehlenden Pakete installieren.
( Es lohnt sich ggf. auch ein "yum install epel-release" und "yum update" ) - Editieren der Datei /etc/pam.d/sshd
Wir deaktivieren die Authentifizierung "password-auth":
Dadurch ist ab heute nur noch ein SSH-Login mit einem Schlüsselpaar möglich.
Wir fügen das Modul pam_google_authenticator.so hinzu:
Durch den Parameter "nullok" akzeptieren wir, dass der Benutzer ggf. beim ersten Login per SSH noch keinen Schlüsselaustausch für den Google-Authentifikator generiert hat.
Ebenfalls fügen wir das Modul "pam_permit.so" hinzu:
So kann man sich nicht nur beim ersten Login per SSH ohne einen generierten Einmal-Schlüssel einloggen, sondern immer:
Der Benutzer kann so selbst entscheiden, ob er (s)einen Authenticator-Key setzen möchte, oder eben explizit nicht.
Das kann z.B. auch sehr wichtig sein, wenn die Maschine remote per Ansible konfiguriert wird.
Aber Vorsicht! Das Modul birgt so seine "Eigenheiten"! - Editieren von /etc/ssh/sshd_config.d/50-redhat.conf
Ja - hier ist eine Besonderheit in Rhel 8 und 9...!
Es besteht ggf. schon die Datei 50-redhat.conf, die einem das Leben schwer macht.
Hinweise:
Unter RHEL/CentOS6 und 7 ist natürlich die Datei /etc/ssh/sshd_conf anzupassen.
Das "Include /etc/crypto-policies..." entfällt dabei natürlich.
Die restlichen Optionen sind aber zu übernehmen.
Es empfiehlt sich noch ggf. die Optionen
PermitEmptyPasswords no
UseDNS=no
hinzu zu nehmen.
Einmal die Konfiguration mit "sshd -t" testen und bei Erfolg mit einem "systemctl restart sshd" neu starten: Das Zauberwerk sollte nun "aktiv" sein.
Es fehlt nun nur noch die Schlüsseldatei für den Google-Authenticator. - Erstellen eines Google-Auth-Tokens
Hans kann nun auf der entfernten Maschine folgendes aufrufen:
Und es beginnt ein heiteres Frage-und-Antwort-Spiel, was der Benutzer individuell für sich selbst entscheiden muss.
Möchtest du zeitbasierte Token aktivieren? Natürlich Yes!
Und schon bekommst du deinen QR-Code, den du natürlich auch im Keepass oder in einem anderen System aufbewahren kannst (beachte die Phrase unterhalb des QR-Codes):
Die Rückmeldung in Form eines 6-Stelligen Schütteltokens von deinem Handy oder sonstigen Gerät gebe nun gleich ein - und dann gibt es schon ein paar "Notfall-Codes", falls einmal die Uhrzeit am Server stehen geblieben ist...
Wir notieren uns diese 5 Codes und also YES - wir wollen das Update!
Wollen wir, dass sich nur eine Person innerhalb von 30 Sekunden mit dem Token einloggen kann? Ich sage NEIN - denn ggf. muss ich grade parallel z.B. in einem MobaXTerm den SFTP-Client frei geben.
Wollen wir ein extra großes Zeitfenster für abweichende Token lassen?
Da sage ich NEIN.
Sollen wir das Rate-Limiting zur Sicherheit aktivieren, so dass mehr als 3 Login-Versuche in 30 Sekunden nicht erlaubt werden? Mnjein.. Ich persönlich wähle hier ein NEIN, weil hier leider nicht fehlerhafte Versuche limitiert werden, sondern anscheinend ALLE Loginversuche.
Auch sollte hier eigentlich schon das fail2ban angeschlagen haben, wenn jemand "herum hämmert" --- und das brauchen wir!
Damit fail2ban auch etwas zu tun bekommt, konfigurieren wir nachher noch einmal ein wenig...
Probier's also mal aus, was nun passiert. :-) - Ausnahmen von der Token-Eingabe - und überhaupt...
Wir haben nun alle SSH-Benutzer des Systems dazu verdonnert, ein TOTP eingeben zu müssen. "Mobile Benutzer" arbeiten auch trotz Corona noch in der Company:
Da wird so ein Token irgendwann ziemlich lästig...
Die Gruppe "mobile Benutzer" soll also am Arbeitsplatz nicht immer zusätzlich zum persönlichen Keyfile auch noch den Authenticator-Token eingeben müssen -
sondern eben nur von "unterwegs aus".
Und wie wäre es nun, auch noch "alle anderen, die keine mobilen Benutzer sind" gleich ganz vom ssh-Zugang aussperren?
Editieren wir noch einmal /etc/ssh/sshd_config.d/50-redhat.conf um die Logik umzukehren:
Niemand soll sich via SSH einloggen, so weit ich ihn nicht genau definiert habe.
Und legen wir die Datei /etc/ssh/sshd_config.d/51-custom.conf an,
um spezielle Benutzer der Gruppe "mobile_benutzer" zu erlauben:
Diese dürfen aus dem lokalen Netz ohne besondere Token-Eingabe sich mit einem Keyfile einloggen. Vom Internet aus wird von den Benutzern jedoch immer das zusätzliche Token benötigt.
Der User Ansible darf nur von 1.2.3.4 kommen - und das mit einem Keyfile.
(Hinweis: Unter RHEL/CentOS 6,7 gehören die folgenden Zeilen natürlich an das Ende von /etc/ssh/sshd_conf . )
Alle anderen, bleiben mit dem üblichen 3-Kennwörter-Procedere vor der Tür -
egal ob Benutzername und dazugehöriges Kennwort falsch oder richtig sind:
Fail2ban hat so etwas zum Loggen.
Nachteile dieser Lösung:
Sofern man einen "lebendigen" Account beim Herumprobieren von draußen findet, wird die Fehlermeldung "permission denied (publickey)" zurück geworfen, anstatt dass wie sonst eine dreifache Kennwort-Abfrage kommt. Wer hier noch eine Idee hat.... gern her damit... :-)
Das sollte es gewesen sein. Have fun!
Keine Kommentare:
Kommentar veröffentlichen