• Désactiver la connexion root - La plupart des attaques automatisées se concentreront sur le compte root, donc interdire les connexions à partir de ce compte est un bon point de départ.

• Autoriser uniquement certains groupes / utilisateurs - Limitez les utilisateurs et les groupes qui peuvent SSH sur le système.

• Limiter par IP ou par plage d'adresses IP : l'un des moyens les plus efficaces de sécuriser votre système contre les attaques SSH.

• Utiliser l'authentification par clé - Comme décrit par Olivier

• Utiliser fail2ban - fail2ban surveillera les tentatives de connexion SSH et après un nombre déterminé de tentatives infructueuses, il bloquera l'adresse IP des attaquants pendant une période de temps définie. Cela peut être une méthode très efficace pour ralentir les attaquants.

Les autres réponses se concentrent sur la sécurisation du serveur - ce qui est important, mais le côté client mérite également une certaine protection:

• Dans / etc / ssh / ssh_config (ou ~ / .ssh / config) définissez StrictHostKeyChecking sur yes ou ask . Cela offre une certaine protection contre les attaques man-in-the-middle en vérifiant que le serveur auquel vous vous connectez est celui que vous attendez.
• Si vous pouvez ajouter des enregistrements à votre zone DNS, publiez un enregistrement SSHFP et définissez VerifyHostKeyDNS sur yes ou ask . Le client récupérera le SSHFP du DNS et vérifiera l'empreinte digitale. (Notez que vous êtes toujours vulnérable si votre attaquant contrôle DNS.)
• Forcer le protocole version 2. I.e. définir le Protocole 2 dans / etc / ssh / ssh_config - la valeur par défaut est 2,1 ce qui permet de revenir à la v1 si la v2 n'est pas disponible.
• Préférez les clés aux mots de passe pour vous connecter. Utilisez un mot de passe fort sur vos clés ssh. Utilisez des clés de longueur adéquate (nombre de bits).
  • Si des utilisateurs fournissent des clés ssh, vérifiez la force du mot de passe en exécutant john sur les clés.
• Utilisez un jeton matériel pour déverrouiller la clé au lieu de taper le mot de passe (pour éviter les keyloggers & épaule surfers).
• Assurez-vous que UseBlacklistedKeys est non (c'est la valeur par défaut). Cela vous empêche d'utiliser des clés «sur liste noire» générées à partir de paquets Debian openssl faibles. Vérifiez les clés d'hôte et d'utilisateur avec ssh-vulnkeys. Sur les systèmes dérivés de Debian (par exemple ubuntu), vous pouvez installer les paquets openssh-blacklist et openssh-blacklist-extra.
• Assurez-vous que CheckHostIP est yes (par défaut). Cela permet au client de vérifier l'adresse IP de l'hôte par rapport aux hôtes connus pour ajouter une protection contre l'usurpation DNS.
• Réglez HashKnownHosts sur yes . Cela empêche les fuites d'informations de votre fichier known_hosts.

La désactivation des connexions basées sur un mot de passe

Le remplacement de l'authentification basée sur un mot de passe par une authentification basée sur une clé empêchera:

• Brute - forcer les tentatives de piratage de mot de passe.
• Attaques à l'épaule: les gens se faufilent derrière pendant que vous tapez votre mot de passe.
• Enregistreurs de frappe.

Autre chose, si seules quelques personnes sont autorisées sur SSH, envoyez un message bashrc à chaque fois que quelqu'un se connecte en SSH

Pour commencer, vous devez interdire les mots de passe et n'autoriser l'authentification qu'à l'aide de clés RSA. Cela rend les attaques par force brute irréalisables. Cependant, les gens essaieront toujours, vous voudrez donc limiter les tentatives de connexion et peut-être changer le port pour économiser votre bande passante. Cette approche repose sur la confiance de vos utilisateurs pour crypter et sécuriser leurs clés privées.

Vous ne devez pas autoriser la connexion root à distance. Utilisez su ou sudo une fois connecté.

Cela peut être une bonne idée d'empêcher les gens de tunneliser ssh via votre serveur de passerelle vers les serveurs internes. Cela peut empêcher vos serveurs internes d'être exposés à Internet.

Vous devez utiliser la version 2 de SSH.

Il me semble qu'aucune des autres réponses ne parle d'un point très important pour sécuriser SSH: éduquer vos utilisateurs . Quoi que vous fassiez, si les utilisateurs n'apprennent pas à réagir de manière raisonnable lorsque quelque chose de louche se produit, vous êtes condamné. À tout le moins, les utilisateurs doivent être conscients de l'activité de gestion des clés du serveur (lorsqu'ils se connectent pour la première fois à un serveur donné, ils doivent vérifier l'empreinte digitale de la clé avec une source fiable; et si SSH met en garde contre une clé cela a changé, ils ne doivent pas contourner l'avertissement).

La technologie ne peut vous mener que jusqu'à présent; tant qu'un humain est impliqué dans le processus, le niveau de conscience de la sécurité de cet utilisateur est une limite absolue au niveau de sécurité que vous pouvez espérer atteindre.

Il existe une nouvelle option sur le serveur pour exiger des mots de passe sur les clés client. Je pense que c'est une très bonne idée. Cependant, vous ne connaissez toujours pas la complexité de la phrase secrète et les utilisateurs pourraient potentiellement recompiler le client pour simuler cela.

Comme tout le monde le dit: désactivez toujours la connexion root, modifiez le numéro de port par défaut (bien que cela puisse rendre l'utilisation de certains clients sftp difficile) et n'acceptez que l'authentification par clé.

De plus, si vous modifiez une clé tailles dans sshd_config ou spécifiez une taille de bit de clé lorsque vous exécutez ssh-keygen, vous devriez revoir les tailles de clé que vous spécifiez de temps en temps.

À l'époque où ssh-keygen par défaut générait des clés RSA 1024 bits que j'ai utilisées pour utiliser l'option -b pour générer des clés de 1536 bits. Au fil du temps, la valeur par défaut a changé pour générer des clés de 2048 bits et je générais toujours des clés de 1536 bits.