> iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state ESTABLISHED -m recent --update --seconds 60 --hitcount 5 -j REJECT --reject-with tcp-reset

Danke für den Tipp, das --update hate bei mir gefehlt.

Wie sieht das denn aus, wenn man immer wieder neue Installationen von Distros auf dem heimischen Rechner ausprobiert, womit
die Schlüssel sich ja ändern, und dann mit diesen Schlüsseln sich auf dem entfernten Server - bei einem Root-Server Hoster -,
wo ja immer das gleiche läuft, somit sich dort die Schlüssel sich nie ändern, versucht sich einzuloggen?

Das habe ich nie verstanden. Es wäre genial, wenn mir mal jemand das erklären würde, bitte.

Ich sehe schon irgendwie, wieso man Permitroot auf no setzen sollte, aber wie bekomme ich es hin, dass meine Schlüssel sich von
Distro zu Distro sich nie ändern?

"Da auch jemand das direkte root-login hier angesprochen hat: Es ist nun wirklich nicht schwer, sich erst als user einzuloggen, und dann mit su root zu werden, dafür hat der angreifer einen Zielpunkt weniger."

Nicht wirklich. root gibts auf jeder Linux/Unixkiste, die normalen Nutzer muss man erstmal finden.

DenyHosts ist mir zu umfangreich. Je umfangreicher eine Software ist, desto mehr potenzielle Fehler besitzt sie. Zudem bringen die ganzen Zusatzfunktionen wie die zentrale Sperrliste kaum einen Sicherheitsgewinn. Ich habe seit 2006 eine eigene Lösung am Rennen und wenn ich über die bisher geblockten Loginversuche Auswertungen fahre dann sehe ich, dass es nur äußerst selten vorkommt, dass eine IP ein zweites mal geblockt werden musste.

Einige der Features sind auch einfach nur gefährlich, wie die unterschiedliche Behandlung existierender und nicht existierender User in dem diesen beispielsweise eine unterschiedliche Anzahl von Loginversuchen bis zur Blockierung gewährt werden. Nicht umsonst macht SSH selbst keinen Unterschied, ob sich ein existierender oder nicht existierender User versucht einzuloggen. Denn durch einen Unterschied verrät man dem Angreifer, bei welchen Usern es sich wirklich lohnt dranzubleiben. Das groteske daran ist, dass man diese Information völlig ohne Not an den Angreifer weitergibt, denn bei nicht existierenden Usern ist sowieso nichts zu holen, es geht also kein Sicherheitsgewinn einher, wenn man diese schneller blockt. In Zeiten von Botnetzen ist der gezielte Angriff mit unterschiedlichsten IP-Adressen und die anschließende Auswertung auch kein Problem mehr.

Viel nützlicher ist dagegen eine Portscan-Auswertung. Viele Angreifer öffnen zuerst eine Verbindung auf Port 22 um festzustellen ob dieser erreichbar ist und schließen sie dann wieder. Erst danach erfolgt der eigentliche Angriff. Geht einem Angriff deshalb ein Portscan voraus, kann man die Anzahl der möglichen Loginversuche herabsetzen, ohne etwas über das eigene System zu verraten.

> Der iptables Eintrag oben im Kommentar hatte nen Nachteil und habe das schnell verworfen. Weiß jetzt
> nicht mehr was, ist schon Jahre her.

Sie blockieren unabhängig von der IP-Adresse des Angreifers und sperren damit alle Nutzer gleichermaßen aus. Man kann sie deshalb hauptsächlich als zusätzlichen Schutz nutzen, um massenweise Anfragen in kürzester Zeit zu blockieren, womit Angreifer versuchen bis zur Reaktionszeit von DenyHosts und Co. möglichst viele Anfragen zu platzieren. Als alleiniger Schutz sind sie oftmals weniger gut geeignet.

In solchen Fällen ist es am sinnvollsten die Existenz des sshd Servers zu verschleiern.
Z.B. in dem man diesen auf einer anderen höheren Portnummer laufen läßt.

Dann wäre ein erst bekannt gewordener Exploit zwar nach wie vor durchaus gefährlich, aber die Wahrscheinlichkeit das der eigene Rechner gehackt wird sinkt.
Denn wer macht sich schon die Mühe und scannt alle 65K Ports irgendeines unbestimmten Rechners ab nur um festzustellen ob darauf sshd läuft?

Nun, selbstverständlich kann man SSH deinstallieren, darum geht es aber nicht.

Manch Serververwalter braucht durchaus SSH um seine Server betreuen zu können.
Nicht jeder Server steht zu Hause oder auf der Arbeit...

hä?
Ohne SSH kann ich meine Server nicht erreichen. Das ist für mich der fundamentalste Dienste überhaupt.

Ich lasse den sshd auf einem nicht Standardport lauschen und erlaube nur einem bestimmten User einen ssh-login und auch nur über einen key.
In den letzten 9 Jahren ist noch keiner in meine Rechner eingedrungen *Holz klopf*.

Wobei es für den Heimanwender auch nur dann uninteressant ist, wenn er nur eine einzige Linux-Büchse in seinem Haushalt hat. Sobald es auch nur irgend wie vernetzt zur Sache geht, ist meine Erfahrung, möchte man über kurz oder lang die Möglichkeit haben, sich "mal eben" auf der anderen anzumelden, um die paar Schritte ins Nachbarzimmer oder Keller zu sparen. Allerdings kann man für ein Heim-Intranet rumdiskutieren, ob man sich dort üerhaupt grosse Gedanken um die Sicherheit zu machen braucht, für den Heimgebrauch wäre sogar telnet sicher genug

Reicht es nicht, ein halbwegs sicheres Passwort zu verwenden? Wenn das Passwort test123 oder der eigene Name etc. ist, braucht man sich auch nicht zu wundern, dass es jemand errät.

Damit hat man das Problem aber nur verschoben. Jetzt ist dein VPN-Server der Angriffspunkt. Allerdings haste dadurch ne zusätzliche Hürde geschaffen, da man, sobald man ins VPN reinkommt, ja immer noch den sshd vor sich hat.