7
CentOS 7 SSH-Härtung auch für KeyAuth?
Hallo Community,
meine Frage gestaltet sich relativ einfach, ich habe ein CentOS Data-Analytik Cluster aufgezogen, und um nun hier diverse Security-Audits von BaFIN , ISO etc zu überstehen muss das Ding natürlich gehärtet sein.
Die sshd_config gestaltet sich wie folgt :
# Authentication:
#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
MaxAuthTries 2
MaxSessions 2
Dies funktioniert auch tadellos, insofern sich der User an der UserDB Authentifiziert.
Sobald man allerdings den Login per SSH-Key vornimmt , welcher mit einer Passphrase versehen ist, greift die Restriktierung auf 2 Login-Versuche nicht, und es ist mir möglich diese zu BF'n.
Kennt ihr einen Weg das abzustellen? Oder bin ich nur zu hastig über die Config-File geflogen.
Mit freundlichen Grüßen,
PoD
meine Frage gestaltet sich relativ einfach, ich habe ein CentOS Data-Analytik Cluster aufgezogen, und um nun hier diverse Security-Audits von BaFIN , ISO etc zu überstehen muss das Ding natürlich gehärtet sein.
Die sshd_config gestaltet sich wie folgt :
# Authentication:
#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes
MaxAuthTries 2
MaxSessions 2
Dies funktioniert auch tadellos, insofern sich der User an der UserDB Authentifiziert.
Sobald man allerdings den Login per SSH-Key vornimmt , welcher mit einer Passphrase versehen ist, greift die Restriktierung auf 2 Login-Versuche nicht, und es ist mir möglich diese zu BF'n.
Kennt ihr einen Weg das abzustellen? Oder bin ich nur zu hastig über die Config-File geflogen.
Mit freundlichen Grüßen,
PoD
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 482046
Url: https://administrator.de/forum/centos-7-ssh-haertung-auch-fuer-keyauth-482046.html
Ausgedruckt am: 23.04.2025 um 17:04 Uhr
7 Kommentare
Neuester Kommentar
Moin,
du verstehst das Verfahren offensichtlich falsch. Die Passphrase des Keys wird nur lokal auf dem Client dazu genutzt den Private Key zu dechiffrieren, das Eingeben des Passwortes wird also nicht als Loginversuch gezählt weil das Passwort niemals den Client verlässt und nichts über die Leitung geht, also tatsächlich kein Loginversuch stattfindet. Erst wenn der User Lokal am Client das richtige Passwort eingibt findet effektiv ein Login-Versuch mit dem jetzt dechiffrierten Key statt und nur der zählt..
Der Key selbst ist mit einem allseits bekannten symmetrischen Verfahren verschlüsselt, der Client weiß also selbst schon vor dem Verbindungsaufbau ob das Passwort des Keys korrekt ist, und erst dann kann ja das asymmetrische Auth-Verfahren durchgeführt werden, nicht vorher. Also alles Tuttifrutti und kein Fehlverhalten..
Lesenswert
https://wiki.archlinux.org/index.php/SSH_keys
Gruß
du verstehst das Verfahren offensichtlich falsch. Die Passphrase des Keys wird nur lokal auf dem Client dazu genutzt den Private Key zu dechiffrieren, das Eingeben des Passwortes wird also nicht als Loginversuch gezählt weil das Passwort niemals den Client verlässt und nichts über die Leitung geht, also tatsächlich kein Loginversuch stattfindet. Erst wenn der User Lokal am Client das richtige Passwort eingibt findet effektiv ein Login-Versuch mit dem jetzt dechiffrierten Key statt und nur der zählt..
Der Key selbst ist mit einem allseits bekannten symmetrischen Verfahren verschlüsselt, der Client weiß also selbst schon vor dem Verbindungsaufbau ob das Passwort des Keys korrekt ist, und erst dann kann ja das asymmetrische Auth-Verfahren durchgeführt werden, nicht vorher. Also alles Tuttifrutti und kein Fehlverhalten..
Lesenswert
https://wiki.archlinux.org/index.php/SSH_keys
Gruß
Failtoban wäre auch noch ein Muss für sowas:
https://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban ...
Zusätzlich noch den sshd statt auf 22 auf einen der Ephemeral Ports zw. 49152 bis 65535 legen.
Dann hast du relative Ruhe. Ansonsten wie immer alle 3 Sekunden irgendwas was schnüffeln oder scannen will...
https://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban ...
Zusätzlich noch den sshd statt auf 22 auf einen der Ephemeral Ports zw. 49152 bis 65535 legen.
Dann hast du relative Ruhe. Ansonsten wie immer alle 3 Sekunden irgendwas was schnüffeln oder scannen will...
Die Nutzung von unprivilegierten Ports für Dinge wie SSH erhöht das Risiko:
Denn auch Nicht-root-Prozesse können sich an diesen Port binden und z.B. nach einem Reboot einen Fake-SSH-Dienst auf diesem Port starten.
Denn auch Nicht-root-Prozesse können sich an diesen Port binden und z.B. nach einem Reboot einen Fake-SSH-Dienst auf diesem Port starten.
Hello,
1) die Bafin macht keine Security Audits.
2) die ISO auch nicht.
deine sshd.config sagt ueberhaupt nichts aus, root no login ?
PublicKey ?
Und was ist die UserDB ?
Gruss
1) die Bafin macht keine Security Audits.
2) die ISO auch nicht.
deine sshd.config sagt ueberhaupt nichts aus, root no login ?
PublicKey ?
Und was ist die UserDB ?
Gruss
Die BaFin und die iso stellen jeweils Benchmarks für die Härtungskonzepte , welche Dannach von Auditoren geprüft werden. Ich weiß ja nicht wo du deine Infos hernimmst, aber wenn du nicht zur Lösung beitragen willst, Spar dir den klick auf den “antworten” Button, thanks ;)
Nein ich hab das ganze nur sehr kurz beschrieben, da entsteht ein falsches Bild, meine Schuld^^
Auch wenn alles "tuttifrutti" ist, ist es dennoch ein enormes Sicherheitsrisiko, insofern ein Client kompromittiert wird, oder sehe ich das falsch?
Kennst du eine Möglichkeit wie ich hier eine Restriction einführen kann?
Vielen Dank für die Hilfe schonmal!
Auch wenn alles "tuttifrutti" ist, ist es dennoch ein enormes Sicherheitsrisiko, insofern ein Client kompromittiert wird, oder sehe ich das falsch?
Kennst du eine Möglichkeit wie ich hier eine Restriction einführen kann?
Vielen Dank für die Hilfe schonmal!
Auch wenn alles "tuttifrutti" ist, ist es dennoch ein enormes Sicherheitsrisiko, insofern ein Client kompromittiert wird, oder sehe ich das falsch?
Ja das siehst du falsch. Das Kennwort ist nur reiner zweiter Faktor, also zum Schutz des Keys selbst da. Ist der Key also einmal in falsche Hände geraten ist dieser sofort am Server zu sperren, dann kann derjenige damit nichts mehr anfangen. Wählt man das Kennwort also lang genug ist im Normalfall genügend Zeit den Key zu sperren, außer der Attacker versucht sich via Cold-Boot Attack oder ähnlichem.Kennst du eine Möglichkeit wie ich hier eine Restriction einführen kann?
Sinnlos da jeder mit jedem anderen beliebigen Client oder commandline-Tool das Passwort des Keys auch via Brute-Force oder Dictionary Attacke hervor holen kann wenn man im Besitz des Keys ist..Private Keys gehören nicht aus der Hand und auch nicht dauerhaft auf dem Client gespeichert, die gehören z.B. auf zusätzlich geschützte Sticks oder andere verschlüsselte Medien, aber niemals einfach so am Client rumliegen gelassen auch wenn sie selbst Passwort geschützt sind. Wie gesagt ist das Passwort nur der zweite Faktor, also lang genug wählen und alles ist gut.
1
