SSH-Verbindung zu VServer mit 2 FA einrichten

fwrede

New Member
Hallo zusammen,

um den Zugriff auf meinen Server möglichst sicher zu gestalten, habe ich versucht, mehrere Sicherheitshürden zu implementieren.

Zum einen habe ich versucht, den Login nur mittels Publickey zu realisieren. Dieser Versuch hat allerdings noch nicht vollständig geklappt, da ich von einem Windows 11 System zugreifen möchte. Über den OpenSSH-Client in der CMD bekomme ich immer einen Fehler, obwohl der öffentliche Schlüssel in der entsprechenden Datei auf dem Server steht. Den genauen Fehler hierfür konnte ich noch nicht vollständig eingrenzen. Da ich jedoch ohnehin plane, von vielen Geräten auf den Server zuzugreifen, wollte ich ohnehin die Möglichkeit des Logins mittels eines Passwortes offen lassen. Daher sah ich es ebenfalls als sehr sicher an, die Passworteingabe um die Eingabe eines 2 FA-Codes zu erweitern.

Allerdings kann ich auch bei dieser Technik kein erfolgreiches Ergebnis vorweisen.
Ich habe zunächst einmal den Google Authenticator auf dem Server (bzw. vorerst in einer VM zum testen) installiert und habe diesen eingerichtet. Dabei bin ich einem sehr guten Video auf Youtube gefolgt. Allerdings besitzt dieses Video als Voraussetzung, dass bereits der Publickey zum Login verwendet wird. Ich aber suche eine Lösung, bei welcher zunächst das Passwort eingegeben wird und im Nachgang ein 2 FA-Code eingeben werden soll.

Folgende Schritte habe ich unternommen (nach Dateien aufgeteilt):
/etc/ssh/sshd_config:
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication yes
AuthenticationMethods password,keyboard-interactive

/etc/pam.d/sshd
#@include common-auth (Auskommentiert)
auth required pam_google_authenticator.so nullok (unten eingefügt)

Teilweise wurden dabei die Zeilen nur einkommentiert und no zu yes geändert. Die Zeilen, welche zuvor in der Datei nicht vorhanden waren, wurden seperat hinzugefügt. Die Schritte unternahm ich auf Anweisung eines sehr guten Videos auf Youtube zum Thema 2 FA bei der Nutzung von SSH.

Nun allerdings wird es kurios:
In der Zeile AuthenticationMethods password,keyboard-interactive schreibt das Video AuthenticationMethods publickey,keyboard-interactive vor. Das kann ich allerdings nicht nutzen. Versuche ich in diesem Moment eine Nutzung, muss ich nur den 2 FA-Code eingeben. Danach verbindet sich SSH korrekt, allerdings weiß ich, dass zuvor die Publickey-Variante nicht funktionierte.
Also habe ich die Zeile geändert auf AuthenticationMethods password,keyboard-interactive . Nun fordert SSH von mir augenscheinlich die Eingabe des Account-Passwortes:
1727818113263.png

Wenn ich dieses allerdings eingebe, wird mir angezeigt, dass es nicht korrekt ist. (Es ist aber korrekt.) Testweise habe ich an der Stelle auch einfach einmal den Google Code eingegeben, und mit dem habe ich Zugriff auf die Maschine bekommen. Also wird an dieser Stelle nicht das Passwort des Accounts abgefragt, sondern erneut nur der Code. Das ist für mich nicht der Sinn von 2 FA, weil ich ja nur einen Faktor (den Code) vorweise und somit nicht sicher genug.

Gibt es jemanden in diesem Forum, der vielleicht einen 2-FA-Schutz für SSH realisiert hat und mir mit diesem Problem helfen kann. Mein Ziel ist es, dass (wie bei der ganz "normalen" SSH-Verbindung, zunächst der Accountname und das Passwort eingegeben werden sollen und im Nachgang dann der Code aus der Authenticator-App.

Zur Information:
Gastsystem: Ubuntu 24.04.01 LTS (derzeit in einer VirtualBox VM, später dann als V-Server. Aufgrund des Sicherheitsaspektes wollte ich die Installation im Vorfeld einmal durchspielen, ohne das es zu Problemen kommt.)
Zugriffssystem: Windows 10/Windows 11 Systeme, am liebsten direkt über die CMD

Ich würde mich über eine Antwort sehr freuen.

Viele Grüße und vielen Dank bereits im Voraus.
 
Hallo,

meiner Erfahrung nach geht nur Key oder OTP. Sichere deinen Server per Key Login, verbiete Root Zugang und erlaube nur Verbindung über einen lokalen VPN Server.

Easy.
 
meiner Erfahrung nach geht nur Key oder OTP

libpam-google-authenticator macht TOTP durchaus zusammen mit einem Passwort. Muss im PAM Stack entsprechend hintereinander gesetzt werden. Dann kann OpenSSH gegen PAM authentifizieren.

.A.
 
Sichere deinen Server per Key Login, verbiete Root Zugang und erlaube nur Verbindung über einen lokalen VPN Server.
Falls wir schon über Jump-Hosts reden und Sicherheit an erster Stelle steht, würde ich stark empfehlen statt oder zusätzlich zu einem VPN-Servers einen Bastion/Privilege-Server mit Access Control zu verwenden.
Ein paar Vorschläge: hoop.dev , Cloudflare Access, ...
Alternativ als "Bastellösung" eine Bastion-VM mit allen denkbaren Sicherheitsmethoden (Duo Free + PAM-Modul, TOTP, ...) und SSH-Keys welche host-gebunden sind auf den anderen Maschinen.
 
Und wer sichert die (in)direkt beteiligten 3rd-Partys und Clients?

Schon lustig dass hier niemand empfehlen würde einen EdDSA-SSH-Key in der Cloud abzulegen, aber bei 2FA wird teilweise nichtmal das absolute Minimum an Security eingefordert...

Wer nutzt 2FA per SMS, eMail, Messanger, etc.?
 
Wer nutzt 2FA per SMS, eMail, Messanger, etc.?
Nutze ich alles nicht. Dafür 16 stellige Passwörter welche für Bruteforce auch heuzutage recht lange dauern dürften. Ich hatte mal überlegt den SSH auf allen Systemen zu deaktivieren. Dann lässt man ein Skript jede Minute ablaufen welches einen Ordner nach einer bestimmten Datei abfragt. Sobald diese Datei vorhanden ist wird der SSH gestartet, die Datei wird gelöscht nach erfolgreichem Start und man kann sich einloggen. Zum ausschalten wird eine andere Datei abgelegt. Muss halt ein Ordner sein der per FTP erreicht werden kann.
Aber ich habe das wieder verworfen und nutze für die normalen User 16 stellige Passwörter aktuell und root darf gar nicht rein.
 
Danke @sbr2d2 ich dachte schon, ich wäre der letzte vernünftige Admin da draussen...

Ein passwortgeschützer SSH-Key ist bereits (simples) 2FA und dabei so gar sicherer als fast alle anderen ausgewachsenen 2FA-Lösungen...
 
Ein passwortgeschützer SSH-Key ist bereits (simples) 2FA
Nein. Der Key wird clientseitig entschlüsselt, damit ist es prinzipbedingt Singlefaktor.

Und wer sichert die (in)direkt beteiligten 3rd-Partys und Clients?
Davon abgesehen dass es sich bei meinen genannten Vorschlägen um etablierte Technologien und Anbieter handelt, alle Faktoren sind einzeln immer so zu wählen dass sie einzeln ein für Aussenstehende unüberwindliches Problem darstellen. Sprich, langes Passwort oder Keypair UND ToTP-Authentisierung. Es geht hier nicht darum dass das Passwort wegen TOTP dann "AlleMeineEntchen" sein darf.


Wer nutzt 2FA per SMS, eMail, Messanger, etc.?
So ziemlich alle grossen Webshops. Weil, schlicht gesagt, es ist "good enough" und einfach für deren Einsatzzweck und sicherlich auch für einen 1€ VPS auf dem die Webseite von Bello gehosted wird.
Bei zB unserem nationaler PKI-Anbieter der es auch tut finde ich das aber hingegen gewagt.

Aber ich habe das wieder verworfen und nutze für die normalen User 16 stellige Passwörter aktuell und root darf gar nicht rein.
Eine etwas angestaubte Technik aber durchaus noch sehr funktional und im Gegensatz zur Verwendung zusätzlicher Zugangsdaten, zusätzlicher Ports, zusätzlicher Dienste sehr simple Alternative wäre eventuell Portknocking.
 
Von "geknackten" 2FA per SMS (weil unverschlüsselt in Plaintext übertragen) lesen wir seit Jahren, ebenso von ebenfalls anfalligen Authenticator Apps, oder Telegram-Bots (denn auch Telegram verschlüsselt nicht per Default)...

Von "geknackten" passwortgeschützten SSH-Keys habe ich in 26 Jahren nicht ein einziges Mal gelesen...
 
Von "geknackten" passwortgeschützten SSH-Keys habe ich in 26 Jahren nicht ein einziges Mal gelesen...
Ich habe keinen direkten Nachweis dass der alte (aber nicht 26 Jahre alte) Debian Openssl Bug aus 2008 öffentlich bekannt exploited wurde.
Wohl aber starke Anzeichen dass das gleiche Problem bei anderen Cryptographien durchaus noch der Fall ist. Und es würde mich nicht wundern wenn sogar der eine oder andere hier noch SSH-Keys aus dieser Zeitperiode hat. Also nur im Homelab versteht sich, wir sind ja alle Profis :cool:

Von "geknackten" 2FA per SMS (weil unverschlüsselt in Plaintext übertragen) lesen wir seit Jahren, ebenso von ebenfalls anfalligen Authenticator Apps
Meine Betonung liegt auf "good enough".
Sollte man eine Nuklearzentrale damit absichern? Absolut nein.
Würde es den 1€ VPS, welcher eher schlecht als recht ein Wordpress hosted, sichern? Ja
Würde ich SMS Singlefaktor empfehlen? Nein. Würde ich TOTP, Duo, ... als Multifaktor dafür empfehlen? Ja.
 
Das Debian-Debakel hat aber rein gar nichts mit passwortgeschützten SSH-Keys zu tun.

Aber ja, der Bug aus dem Debian-Debakel wurde tausendfach ausgenutzt und wird es teilweise noch heute.


Naja, das nächste riesengrosse Sicherheitsproblem verbreitet sich ja gerade rasant: Passkeys
Wird extrem lustig wenn die uns um die Ohren fliegen und das werden sie definitiv, es ist nur die Frage wann es knallt...
 
Naja, das nächste riesengrosse Sicherheitsproblem verbreitet sich ja gerade rasant: Passkeys
Wird extrem lustig wenn die uns um die Ohren fliegen und das werden sie definitiv, es ist nur die Frage wann es knallt...
Könntest du dazu bitte etwas Kontext liefern und erläutern, warum es deiner Meinung nach definitiv knallen wird?
 
Das Debian-Debakel hat aber rein gar nichts mit passwortgeschützten SSH-Keys zu tun.
Das ist ja mein Punkt, es betrifft schlicht alle SSH Keys. Die entsprechenden SSH Keys sollten alle als geknackt angesehen werden. Hier ging es ja um die Server-Client Authentisierung, dort spielt das Passwort des SSH-Keys keine Rolle da es lediglich einen Schutz gegen data-at-rest Attacken den Client hergibt.
Falls du dich auf den Passwortschutz (der nicht in der Client-Server Authentisierung mitspielt) selber berufst so stimme ich zu dass mir auch keine öffentlichen Fälle von erfolgreicher reiner bruteforce auf SSH-Privatekeys bekannt sind. Natürlich sind hashcat und johntheripper in der Lage über Zusatztools (JohncrackSSH) dictionary-Attacken zu fahren.



das nächste riesengrosse Sicherheitsproblem verbreitet sich ja gerade rasant: Passkeys
Passkeys sind IMHO ein deutlicher Schritt nach oben für durchschnittliche und überdurchschnittliche Benutzer. Die Entkopplung der Passwörter gegenüber dem User in einen TPM hinein auf einem trusted device erhöht die Komplikationen von Fern-Attacken immens.
 
Back
Top