Wenn es sich absolut nicht vermeiden lässt den SSH-Zugang bereitzustellen, dann sollte er zumindest so gut gesichert wie möglich laufen. Dazu habe ich mir einige Gedanken gemacht und das ein oder andere aus dem Web zusammengetragen und kombiniert.
Physische Anwesenheit
Der beste Weg ist, wenn man keinen SSH-Server laufen hat, den man angreifen kann. Der Nachteil ist dann natürlich, dass man physisch anwesend sein muss. Für das schnelle fixen eines Problem per remote ist das natürlich nichts.
Kein direkter Zugriff auf SSH
Wer die Möglichkeit hat über ein VPN den Server zu erreichen, der sollte sich dafür möglicherweise entschließen. Der SSH-Port ist von außen (Internet) nicht erreichbar. Ein Scan würde also nichts zutage fördern.
Das Zeitfenster für den Zugriff
Sofern es absehbar ist, dass der Zugang nur zu bestimmten Zeiten nötig ist, sollte man bspw. per Firewall dafür sorgen, dass der Port auch nur dann offen ist.
Root-Zugang deaktivieren
Es ist immer eine gute Idee den direkten Login als Root zu vermeiden. Dazu ist in der sshd_config die Direktive "PermitRootLogin no" zuständig. Steht er auf "yes", dann kann der Root sich sofort einloggen. Der bessere Weg ist über einen normalen Benutzer zu gehen. Da meist der Benutzername nicht bekannt ist, ist das eine weitere kleine Hürde, die der Angreifer nehmen muss.
Public Key Authentication
Noch besser ist, wenn der Benutzer sich nicht per Passwort, sondern per Public Key Auth identifizieren muss. Dazu wird in der sshd_config die Direktive "PubkeyAuthentication yes" gesetzt. Zeitgleich deaktiviert man den Passwortlogin mit "PasswordAuthentication no".
Anzahl Loginversuche eingrenzen
Obendrein kann man die Anzahl der möglichen Loginversuche auf eine bestimmte, angemessene Anzahl eingrenzen. Das macht man recht einfach mit Fail2Ban. Nach einer Anzahl X erfolgloser Loginversuche sperrt Fail2Ban per NetFilter-Regel (iptables) die IP des Angreifers.
Schlüssellänge nicht unter 2048 Bit
Laut BSI ist eine Schlüssellänge größer als 2048 Bit erst ab 2024 sinnvoll. Bis dahin reicht sie völlig aus. Kleinere Schlüssel sollten nicht verwendet werden. Empfohlen wir RSA 2048 Bit Schlüssel.
Port 22 ändern
Den SSH-Serverport 22 sollte man auf einen Port > 45000 ändern, um zumindest den Bot-Angriffen aus dem Weg zu gehen, da diese meist nur den Standartport ausprobieren.
SSH-Zugriff nur von einer bestimmten IP/Netz erlauben
Es hilft, wenn man den Zugriff auf den SSH-Server eingrenzt, in dem man mittels IP-Tables dafür sorgt, dass dieser nur von einer bestimmten IP aus (Client-IP ist gemeint) erlaubt ist. Das ist interessant für kleine Unternehmen, die eine feste IP an ihrem DSL-Anschluss haben. In diesem Fall hilft wieder iptables.
Zugang nur bestimmten Benutzern erlauben
Mit der Direktive "allowusers" in der sshd_config bestimmt man den Kreis der Benutzer, die sich überhaupt per SSH einloggen dürfen. Das Gegenstück dazu ist "denyusers", um bestimmte Benutzer auszuschließen.
Benutzername muss nicht Paul sein
Es spricht überhaupt nichts dagegen, dass auch der Benutzername a) länger und b) mit Zahlen und Zeichen versehen ist. Statt Paul könnte es auch P4/L7%#.2Tf sein.