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_absichern
>
> --
> 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