zwei SSH-probleme

[theomega]

Hallo Leute
ich habe zwei Fragen zum SSH-Server auf meinem Suse 8.1:

1. Wie kann den Login so verändern, dass nach 3 Passwort-Fehleingaben die IP gesperrt wird? Damit würde man Bruteforce einigermaßen unterbinden können

2. Wie kann ich verhindern, das ich nach ca. 2 Minuten "nichtstun" ausgelogt werde?

Danke

TO

[cybernd]

zum 2.

falls du dich per putty einlogst findet sich in den einstellungen eine option für ein aufrechterhalten der verbindung .. einfach alle 60 sekunden ein null paket hinschicken lassen

ist halt clientabhängig .. d.h. diese einstellung in deinem wunschclient suchen und bingo es müsste gehen

zum anderen prob hmmm da muß ich leider passen :o)

hth
cybi

[jtb]

1. Wie kann den Login so verändern, dass nach 3 Passwort-Fehleingaben die IP gesperrt wird? Damit würde man Bruteforce einigermaßen unterbinden können

verwende max_startups

[theomega]

Ich habe MaxStartup mal testweise auf 3 gesetzt, tortzdem werde ich erst nach 10 Fehlversuchen gekickt und kann dann gleich nochmal versuchen, also ist meine IP nicht gesperrt.

[Matthias Diehl]

hast Du nach der Umstellung auch ssh neu gestartet ?
Das mit IP sperren geht nur über iptables oder ähnliches. Das geht nicht über die shh config

[jtb]

Ich habe MaxStartup mal testweise auf 3 gesetzt, tortzdem werde ich erst nach 10 Fehlversuchen gekickt und kann dann gleich nochmal versuchen, also ist meine IP nicht gesperrt.

MaxStartups
Specifies the maximum number of concurrent unauthenticated con-
nections to the sshd daemon. Additional connections will be
dropped until authentication succeeds or the LoginGraceTime ex-
pires for a connection. The default is 10.

Alternatively, random early drop can be enabled by specifying the
three colon separated values ``start:rate:full'' (e.g.,
"10:30:60"). sshd will refuse connection attempts with a proba-
bility of ``rate/100'' (30%) if there are currently ``start''
(10) unauthenticated connections. The probability increases lin-
early and all connection attempts are refused if the number of
unauthenticated connections reaches ``full'' (60).

Man muss nicht unbedingt die IP sperren um Bruteforce zu verändern (ein DSL-Flat würde sich einfach neu einwählen!), sondern man kann Wartezeiten für Fehlgeschlagene Logins einbauen und das geht mit maxstartups..

Eventl. hast du deinen sshd nicht neugestartet?

[theomega]

Ich verstehe diese Angaben nicht ganz, welche wären den sinnvoll?

[dodolin]

1. Wie kann den Login so verändern, dass nach 3 Passwort-Fehleingaben die IP gesperrt wird? Damit würde man Bruteforce einigermaßen unterbinden können

MaxStartups ist für was anderes zuständig und hilft hier nicht weiter. Ich würde sowas ja lieber über pam regeln. Ist auch viel eleganter. :-D
Der Linux-PAM System Administrators' Guide (http://www.kernel.org/pub/linux/libs/pa ... l/pam.html) ist wirklich für jeden Admin sehr empfehlenswert. Das für diesen Zweck gesuchte Modul findest du unter http://www.kernel.org/pub/linux/libs/pa ... tml#ss6.24. Die meisten (oder alle?) SSHDs sollten sowieso schon gegen pam gelinkt sein. Einfach mal in /etc/pam.d/ nachgucken, ob es dort ein file sshd oder sowas gibt. Dort dann das tally Modul entsprechend mit den gewünschten Optionen verlinken.

2. Wie kann ich verhindern, das ich nach ca. 2 Minuten "nichtstun" ausgelogt werde?

Auch dass das nur eine Client-Option wäre, ist falsch. In der man-page zu sshd sind hierzu die Optionen ClientAliveInterval, ClientAliveCountMax und KeepAlive von Interesse.

Ich würde das Problem mit der Bruteforce-Attacke allerdings etwas anders angehen:
Entweder Passwort-Login komplett deaktivieren und Login nur noch per PubKeyAuthentication zulassen oder wenn ein Passwort-Login unbedingt nötig ist, hierzu einen separaten User anlegen, der ansonsten keinerlei Rechte hat und per AllowUsers (DenyUsers) ausschliesslich diesem User den Login erlauben. Dann mit su arbeiten. So müssten mindestens 2 Passwörter (die man halt gut (tm) wählen sollte) geknackt werden und mit dem 1. gecrackten Account könnte man (bis auf Local Exploits, die ja bei einem zeitnah gepatchten System eh nicht funktionieren dürften... :-D ) noch nichts anfangen.

[theomega]

Ã?hm, das mit den Keys hört sich sehr interessant an, wie funktioniert dass dann? Das jeder User, der Zugriff aus SSh haben will, eine bestimmte Keyfile haben muß? das wäre ideal!

[[tom]]

Damit würde man Bruteforce einigermaßen unterbinden können

Brute Force online gegen einen Account macht eigentlich keiner. Eher Dictonary.

Wenn Du "starke" Passwörter hast, würde es rein rechnerisch lokal auf einem Rechner, der 40.000.000 Vergleiche pro Sekunde schafft, ca. 50 Jahre dauern, bis er alle Kombinationen durch hat (bei Standard DES).

Bei "schwachen" kann man mit einem Dictionary allerdings schon Erfolg haben.

Also - immer starke Passwörter. ;-)

Und noch ein kleiner Tipp: root Login disablen und einen User anlegen, der nicht einfach zu raten ist (also nicht admin, tom usw.). Der Username ist die halbe Miete.

[TOM]

[theomega]

Will heißen, die Chance, das ein 10 Stelliges Passwort auf Zahlen und Buchstaben in einer wirren Kombination eher nicht zu knacken sind?

[sascha]

Am besten schaltet man den Passwort Login komplett aus und logt sich nur mit einem RSA Key ein.

[theomega]

und wie funktioniert das dann? Was müßen die User auf dem PC haben?

[dodolin]

Ã?hm, das mit den Keys hört sich sehr interessant an, wie funktioniert dass dann? Das jeder User, der Zugriff aus SSh haben will, eine bestimmte Keyfile haben muß? das wäre ideal!

Ja.

Blöd wird es halt dann, wenn man sich z.B. von unterwegs einloggen will und man
a) den Key nicht dabei hat oder
b) ihn zwar z.B. auf Diskette mit hat, aber der momentan verfügbare Rechner kein Laufwerk hat.

Ansonsten ist das aber IMHO eindeutig vorzuziehen.

Wie es geht? Hm... die Doku ist da eigentlich ganz gut. Ich bin ja immer nach der Anleitung auf http://atiswww.ira.uka.de/studentisches ... _ohne.html vorgegangen, weil es halt von meiner Uni ist. Aber ehrlich gesagt, ist die Anleitung in dieser Form nicht zu gebrauchen, da fast alle Pfade und Dateien auf meinem Linux anders hiessen. Naja, mit ein bisschen Eigenintelligenz und den man-pages zu sshd und ssh kriegt man es dann aber hin. Eigentlich sollten auch die man-pages alleine schon ausreichen.

In der Konfig zum SSHD sind folgende Optionen interessant (siehe man-page):
AuthorizedKeysFile (so muss das File heissen, das im $HOME des jeweiligen Users liegen muss)
PasswordAuthentication (sollte dann auf "no" stehen)
PermitRootLogin (sollte sowieso immer auf "no" stehen)
Protocol ("2" genügt, "1" ist unsicher)
PubkeyAuthentication (sollte natürlich dann auf "yes" stehen)
sowie die bereits erwähnten Optionen
AllowUsers und DenyUsers (gibt es auch mit Groups).

Wie der Client konfiguriert wird, wird in der recht ausführlichen man-page zu ssh beschrieben.