Alternativ könnte man vielleicht auch einen Satz Yubikeys für die ganze Einrichtung bestellen und 2FA auf dem Server erzwingen.
OpenSSH unterstützt seit Version 8.2 FIDO2 nativ. Dann liegt dein Key entweder immer verschlüsselt auf dem Rechner (oder dem Authenticator, Stichwort "resident keys") und wird beim Verbinden durch den Authenticator entschlüsselt. Wenn der Authenticator noch eine PIN abfragt, hast du sogar zwei Faktoren und der Authenticator kann nicht von jedem verwendet werden. Nachteil: da der Private-Key nie unverschlüsselt den Authenticator verlässt, dürften Agents nicht funktionieren. On Fri, 17 Apr 2020 at 15:36, Xhonneux, René <xhonneux@ub.rwth-aachen.de> wrote:
Hallo Stephan,
grundsätzlich befürworte ich auch Public-Key-Authentifizierung, aber unter Linux z.B. liegt der nicht geschützte Schlüssel dann ja regulär unverschlüsselt unter ~/.ssh/id_rsa - eine Malware auf dem Rechner oder evtl. auch nur eine Sicherheitslücke im Browser, die Zugriff auf's Dateisystem erlaubt, und schon könnte der Schlüssel weg sein.
Vielleicht ist das nur meine Paranoia, aber da hätte ich irgendwie immer ein ungutes Gefühl. Alternativ könnte man vielleicht auch einen Satz Yubikeys für die ganze Einrichtung bestellen und 2FA auf dem Server erzwingen.
Danke für den Link zu fail2ban, schaue ich mir mal an. Die Pluggable Authentication Modules haben allerdings den Charme, dass sie auch einen Schutz gegenüber lokalen Angreifern bieten können, deren Verwendung würde ich persönlich unabhängig davon auch immer empfehlen.
Grüße, René
On Fri, 2020-04-17 at 15:10 +0200, Krinetzki, Stephan wrote:
Hallo René,
aus meiner Sicht ist es eigentlich egal, ob der private Key mit Passwort geschützt ist oder nicht. Da man den Key erstmal haben muss. Und solange der Key nicht irgendwo verteilt wird oder "mitgenommen" wird, ist das deutlich sicherer als mit einem Passwort. Natürlich ist auch besser, den Key mit einem Passwort zu sichern, dann hat man ja zwei Hürden: Man muss den private Key haben und muss dazu das Passwort kennen. Aber allein in den Besitz eines solchen Keys zu kommen sollte nicht ganz einfach sein.
Ich persönliche sichere meinen privaten Server noch mit fail2ban [0] ab. Da beobachte ich das SSH Log und sehe, wer sich dort versucht wie anzumelden. Sollten zu viele Login Versuche passieren, so wird die entsprechende IP für 2h per iptables gebannt. So kann man auch recht gut einem gezielten Angriff entgegen wirken. Die Anzahl der Versuche und Sperrdauer ist dabei leicht anzupassen, würde mit kurzen Zeiten anfangen und das dann irgendwann verlängern. Man kann auch, wie ich es gemacht habe, mit zwei Jails arbeiten: Einem kurzen und bei wiederholten Verstößen, einen langen Jail. Im kurzen sind es wenige Stunden, im langen 2 Tage sperre.
Gruß
Stephan
[0]
https://www.thomas-krenn.com/de/wiki/SSH_Login_unter_Debian_mit_fail2ban_abs...
-- Stephan Krinetzki
IT Center Gruppe: Systemgruppe Linux Abteilung: Systeme & Betrieb RWTH Aachen University Seffenter Weg 23 52074 Aachen Tel: +49 241 80-24866 Fax: +49 241 80-22134 krinetzki@itc.rwth-aachen.de www.itc.rwth-aachen.de
-----Original Message----- From: Xhonneux, René <xhonneux@ub.rwth-aachen.de> Sent: Friday, April 17, 2020 3:00 PM To: rwth-security@lists.rwth-aachen.de Subject: [rwth-security] Re: Status SSH
Hallo,
meine größte Sorge Public-Key-Authentifizierung auf dem Server zu erzwingen wäre, wie man dann auch alle Anwender dazu erzieht den private key mit einem starken Passwort zu schützen und gegebenenfalls einen SSH-Agent zu verwenden.
Andernfalls ist der private key IMHO nur so vertrauenswürdig wie der Rechner, auf dem er genutzt wird und wenn die Prämisse schon "Public- Key-Authentifizierung weil unsichere Passwörter" ist ...
Verlagere ich das Problem damit nicht nur? Wie wird so etwas in anderen Einrichtungen / Instituten gehandhabt?
Auf der anderen Seite schätze ich das Risiko für einen erfolgreichen SSH-Login via Passwörter durchprobieren für sehr gering ein, wenn im Vorfeld gängige security best practices umgesetzt werden, u.a.
* Forcieren von Passwortrichtlinien * Automatische Sperrung von Benutzerkonten nach X fehlgeschlagenen Logins
Gibt es einen guten Grund seine Linuxserver nicht entsprechend mit PAM und Modulen wie pam_faillock oder pam_tally zu schützen?
Grüße, René
-- René Xhonneux Dezernat Informationstechnologie (IT) IT-Service
Universitätsbibliothek RWTH Aachen University Templergraben 61 52062 Aachen Tel: +49 241 80-94560 Fax: +49 241 80-92273 xhonneux@ub.rwth-aachen.de www.ub.rwth-aachen.de
Sprechstunden: Mo. - Fr.: 09:00-15:00 Uhr
_______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de