• Root-Anmeldung deaktivieren - Die meisten automatisierten Angriffe konzentrieren sich auf das Root-Konto. Das Ablehnen von Anmeldungen von diesem Konto ist daher ein guter Ausgangspunkt.

• Nur bestimmte Gruppen / Benutzer zulassen - Beschränken Sie, welche Benutzer und Gruppen SSH für das System verwenden können.

• Begrenzung nach IP oder IP-Bereich - Eine der effektivsten Möglichkeiten, Ihr System vor SSH-Angriffen zu schützen.

• Schlüsselbasierte Authentifizierung verwenden - Wie von Olivier beschrieben

• Verwenden Sie fail2ban - fail2ban überwacht versuchte SSH-Anmeldungen und blockiert nach einer bestimmten Anzahl fehlgeschlagener Versuche die IP-Adresse des Angreifers für einen festgelegten Zeitraum. Dies kann eine sehr effektive Methode sein, um Angreifer zu verlangsamen.

Die anderen Antworten konzentrieren sich auf die Sicherung des Servers - was wichtig ist, aber auch die Clientseite verdient einen gewissen Schutz:

• In / etc / ssh / ssh_config (oder ~ / .ssh / config) Setzen Sie StrictHostKeyChecking auf yes oder ask . Dies bietet einen gewissen Schutz vor Man-in-the-Middle-Angriffen, indem überprüft wird, ob der Server, mit dem Sie eine Verbindung herstellen, der erwartete ist.
• Wenn Sie Ihrer DNS-Zone Einträge hinzufügen können, veröffentlichen Sie einen SSHFP-Eintrag und Setzen Sie VerifyHostKeyDNS auf yes oder ask . Der Client ruft das SSHFP vom DNS ab und überprüft den Fingerabdruck. (Beachten Sie, dass Sie immer noch anfällig sind, wenn Ihr Angreifer DNS kontrolliert.)
• Protokollversion 2 erzwingen. setze Protokoll 2 in / etc / ssh / ssh_config - der Standardwert ist 2,1 , wodurch auf v1 zurückgegriffen werden kann, wenn v2 nicht verfügbar ist.
• Ziehen Sie Schlüssel für die Anmeldung Passwörtern vor. Verwenden Sie ein sicheres Passwort für Ihre SSH-Schlüssel. Verwenden Sie Schlüssel mit ausreichender Länge (Anzahl der Bits).
  • Wenn Benutzer SSH-Schlüssel bereitstellen, überprüfen Sie die Kennwortstärke, indem Sie john auf den Schlüsseln ausführen.
• Verwenden Sie ein Hardware-Token, um den Schlüssel zu entsperren, anstatt das Kennwort einzugeben (um Keylogger von &-Schulter-Surfern zu vermeiden).
• Stellen Sie sicher, dass UseBlacklistedKeys no (dies ist die Standardeinstellung). Dies verhindert, dass Sie Schlüssel auf der schwarzen Liste verwenden, die während schwacher Debian-openssl-Pakete generiert wurden. Überprüfen Sie die Host- und Benutzerschlüssel mit ssh-vulnkeys. Auf von Debian abgeleiteten Systemen (z. B. Ubuntu) können Sie die Pakete openssh-blacklist und openssh-blacklist-extra installieren.
• Stellen Sie sicher, dass CheckHostIP yes code ist > (Standardeinstellung). Dadurch überprüft der Client die IP des Hosts anhand bekannter_Hosts, um den Schutz vor DNS-Spoofing zu erhöhen.
• Setzen Sie HashKnownHosts auf yes . Dies verhindert, dass Informationen aus Ihrer Datei "unknown_hosts" verloren gehen.

Deaktivieren kennwortbasierter Anmeldungen

Durch Ersetzen der kennwortbasierten Authentifizierung durch schlüsselbasierte Authentifizierung wird Folgendes verhindert:

• Brute - Versuche zum Knacken von Passwörtern erzwingen.
• Schulterangriffe: Personen, die sich hinterher schleichen, während Sie Ihr Passwort eingeben.
• Key Logger

Eine andere Sache, wenn nur wenige Personen auf SSH erlaubt sind, machen Sie bashrc eine E-Mail, wenn sich jemand bei SSH anmeldet

Zunächst sollten Sie Kennwörter nicht zulassen und die Authentifizierung nur mit RSA-Schlüsseln zulassen. Dies macht Brute-Force-Angriffe unmöglich. Leute werden es jedoch weiterhin versuchen, daher sollten Sie die Anmeldeversuche begrenzen und möglicherweise den Port ändern, um Ihre Bandbreite zu sparen. Dieser Ansatz beruht darauf, dass Sie Ihren Benutzern vertrauen, dass sie ihre privaten Schlüssel verschlüsseln und sichern.

Sie sollten die Root-Anmeldung nicht remote zulassen. Verwenden Sie su oder sudo, sobald Sie angemeldet sind.

Es kann eine gute Idee sein, zu verhindern, dass Benutzer ssh über Ihren Gateway-Server zu internen Servern tunneln. Dies kann verhindern, dass Ihre internen Server dem Internet ausgesetzt werden.

Sie sollten Version 2 von SSH verwenden.

Mir fällt auf, dass keine der anderen Antworten einen sehr wichtigen Punkt für die Sicherung von SSH betrifft: Schulung Ihrer Benutzer . Was auch immer Sie tun, wenn die Benutzer nicht lernen, vernünftig zu reagieren, wenn etwas faul passiert, sind Sie zum Scheitern verurteilt. Zumindest müssen Benutzer über das Geschäft mit der Verarbeitung von Serverschlüsseln informiert sein (wenn sie zum ersten Mal eine Verbindung zu einem bestimmten Server herstellen, müssen sie den Schlüsselfingerabdruck mit einer zuverlässigen Quelle überprüfen und SSH vor einem Schlüssel warnen das hat sich geändert, sie dürfen die Warnung nicht umgehen.

Technologie kann Sie nur so weit bringen; Solange ein Mensch in den Prozess involviert ist, ist das Sicherheitsbewusstsein dieses Benutzers eine harte Grenze für das Sicherheitsniveau, das Sie möglicherweise erreichen möchten.

Auf dem Server gibt es eine neue Option, die Passphrasen für die Clientschlüssel erfordert. Ich denke, das ist eine sehr gute Idee. Sie kennen die Komplexität der Passphrase jedoch immer noch nicht und Benutzer könnten den Client möglicherweise neu kompilieren, um dies zu fälschen.

Wie alle sagen: Deaktivieren Sie immer die Root-Anmeldung, ändern Sie die Standardportnummer (obwohl dies die Verwendung einiger SFTP-Clients erschweren kann) und akzeptieren Sie nur die schlüsselbasierte Authentifizierung.

Auch wenn Sie einen Schlüssel ändern Größen in sshd_config oder geben Sie eine Schlüsselbitgröße an, wenn Sie ssh-keygen ausführen. Sie sollten die von Zeit zu Zeit angegebenen Schlüsselgrößen überprüfen.

Damals, als ssh-keygen standardmäßig 1024-Bit-RSA-Schlüssel generierte, die ich verwendet habe Verwenden Sie die Option -b, um 1536-Bit-Schlüssel zu generieren. Im Laufe der Zeit änderte sich die Standardeinstellung, um 2048-Bit-Schlüssel zu generieren, und ich generierte immer noch 1536-Bit-Schlüssel.