Quels sont les problèmes de sécurité possibles avec un démon SSH ?

La plus grande préoccupation serait que les personnes se connectent en tant qu'administrateur de l'ordinateur via SSH. Cela peut être fait par force brute si vous avez un mot de passe facile à deviner.

Il existe plusieurs mesures de sécurité que vous pouvez prendre, voici quelques-unes de celles que je prends toujours lors de la configuration d'un serveur SSH et quelques autres.

Utilisez un mot de passe fort, composé d'au moins (disons) 10 lettres majuscules et minuscules, chiffres et autres caractères.
Emprisonne les utilisateurs dans leur répertoire personnel. Les utilisateurs emprisonnés ne pourront pas accéder/modifier les fichiers qui se trouvent en dehors de leur répertoire personnel. Ainsi, votre utilisateur ne pourra pas accéder/modifier les fichiers système clés. De nombreux tutoriels peuvent être trouvés en ligne sur la façon d'emprisonner un utilisateur. La plupart d'entre eux utilisent JailKit. Un exemple d'un tel tutoriel peut être trouvé ici. Alternativement, vous pouvez également utiliser le ChrootDirectory natif du serveur OpenSSH directif. Un exemple de tutoriel à ce sujet peut être trouvé ici.
Installez Fail2Ban. Fail2Ban est un programme qui vérifie les journaux d'authentification pour les entrées erronées. Lorsqu'une certaine limite est atteinte, il ajoute un bloc de pare-feu pour cette certaine adresse IP pendant une durée prédéfinie. Il existe également plusieurs didacticiels en ligne trouvés en ligne sur la configuration de Fail2Ban avec SSH, un exemple serait celui-ci. La page d'accueil de Fail2Ban contient également des HOWTO agréables et complets.
Désactivez la connexion root via SSH. C'est l'utilisateur qui a accès à pratiquement tous les fichiers de votre système, il est donc recommandé de désactiver sa connexion au shell. Dans les dernières versions d'Ubuntu, l'utilisateur root est automatiquement désactivé, mais cela ne fait pas de mal de désactiver son accès SSH de toute façon. Cela se fait en éditant le fichier /etc/ssh/sshd_config . Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant.
```
#PermitRootLogin no
```
Utilisez un port non standard (par exemple, pas 22) Cela se fait soit via la redirection de port dans votre routeur (par exemple, 16121 -> 22 au lieu de 22 -> 22) soit en faisant écouter le démon SSH sur un port différent. Cela rendra votre service SSH moins facilement détectable par les utilisateurs malveillants. Cela se fait en éditant le fichier /etc/ssh/sshd_config . Recherchez la ligne suivante et remplacez 22 par le port de votre choix. N'oubliez pas de rediriger le bon port dans votre routeur par la suite.
```
Port 22
```
N'utilisez pas de mots de passe pour vous connecter. Outre les mots de passe, SSH permet également de se connecter à l'aide de clés privées. Cela signifie qu'une clé est stockée sur votre ordinateur sur laquelle vous accédez au SSH de la machine SSH. Lorsqu'une connexion est tentée, le client SSH utilise la clé pour se connecter au serveur au lieu de passer par l'authentification par mot de passe. Les clés d'authentification sont cryptographiquement beaucoup plus solides que les mots de passe et ne sont donc pas si faciles à déchiffrer. Il existe également plusieurs didacticiels en ligne trouvés en ligne sur la configuration de l'authentification basée sur une clé avec SSH, un exemple serait celui-ci. (Si vous utilisez SSH depuis Windows avec PuTTY, consultez ce lien pour un tutoriel PuTTY.) Après avoir configuré l'authentification par clé, vous pouvez désactiver l'authentification par mot de passe en modifiant le fichier /etc/ssh/sshd_config . Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant.
```
#PasswordAuthentication no
```
En option, comme @ Linker3000 l'a mentionné dans son commentaire, vous pouvez configurer un tunnel VPN vers le PC auquel vous souhaitez accéder via SSH, puis interdire l'accès au réseau non local sur le serveur SSH. De cette façon, aucun appareil externe sans connexion VPN ne pourra accéder à votre serveur SSH. Cela peut être fait en refusant TOUS les hôtes, puis en autorisant uniquement les adresses IP du réseau local à se connecter. Cela se fait en éditant /etc/hosts.deny et ajoutez ce qui suit :
```
sshd: ALL
```
et à /etc/hosts.allow ajoutez ce qui suit :
```
sshd: 192.168.1.*
```
où l'IP correspond à celle de votre réseau local. * est un caractère générique, donc toutes les adresses IP commençant par 192.168.1. sera accepté. Si cela ne fonctionne pas, votre distribution peut utiliser ssh au lieu de sshd . Dans ce cas, vous devriez essayer ssh: 192.168.1.* et ssh: ALL à la place.
Vous ne pouvez autoriser que des hôtes spécifiques, faites de même avec le /etc/hosts.allow et /etc/hosts.deny comme décrit en 6, mais en /etc/hosts.allow ajoutez la ligne suivante et chaque hôte à autoriser séparés par des espaces :
```
sshd: {IP OF HOST TO ALLOW 1} {IP OF HOST TO ALLOW 2} {IP OF HOST TO ALLOW 3} {ETC.}
```
Autorisez uniquement des utilisateurs spécifiques à accéder à votre serveur SSH. Cela se fait en éditant le fichier /etc/ssh/sshd_config . Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant. S'il n'existe pas, créez-le. Par exemple, si vous souhaitez autoriser uniquement Jean, Tom et Marie, ajoutez/modifiez cette ligne :
```
AllowUsers john tom mary
```
Vous pouvez également refuser des utilisateurs spécifiques. Par exemple, si vous souhaitez refuser l'accès à Jean, Tom et Marie, ajoutez/modifiez cette ligne :
```
DenyUsers john tom mary
```
Autorisez uniquement le protocole SSH2 pour les connexions entrantes. Il existe deux versions du protocole SSH. SSH1 est sujet à des problèmes de sécurité, il est donc recommandé d'utiliser SSH 2. Cela peut être forcé en éditant le fichier /etc/ssh/sshd_config . Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant. S'il n'existe pas, créez-le.
```
Protocol 2,1
```
supprimez le ,1 pour que la ligne soit
```
Protocol 2
```
Ne pas autoriser les utilisateurs à se connecter sans mot de passe défini. Cela peut être forcé en éditant le fichier /etc/ssh/sshd_config . Recherchez la ligne suivante et assurez-vous qu'il n'y a pas de # devant. S'il n'existe pas, créez-le.
```
PermitEmptyPasswords no
```
Et bien que simple et peut-être inutile de le dire, mais crucial dans de nombreux cas, gardez votre logiciel à jour. Mettez régulièrement à jour vos packages/logiciels installés.

=après avoir modifié le fichier de configuration SSH, n'oubliez pas de redémarrer le démon pour appliquer les changements. Redémarrez le démon en exécutant :

sudo /etc/init.d/ssh restart

sudo /etc/init.d/sshd restart

selon la distribution de Linux que vous utilisez.

Quelques conseils :

Utilisez l'authentification basée sur une clé, qui est BEAUCOUP plus sécurisée que les mots de passe
SSH 2 uniquement
Désactiver les connexions root
Pour les paranoïaques, changez le port du port standard 22
Pour plus de commodité, utilisez un outil pour associer votre adresse IP à un nom DNS, comme Dyndns ou son équivalent. Vous pouvez rester longtemps avec la même adresse IP, mais une fois que vous voyagez et que vous en avez besoin, vous vous apercevrez qu'on vous en a délivré une nouvelle.
Bien sûr, n'autorisez que le port nécessaire pour SSH (port 22, ou un port non standard si vous le souhaitez) via votre pare-feu.

Le principal risque est d'oublier que vous utilisez un serveur ssh et de mettre un mot de passe faible sur un compte. Il existe des attaquants qui essaient systématiquement les noms de compte courants (comme webmaster et bob ) et des mots de passe faibles. Vous pouvez supprimer ce risque en interdisant les logins par mot de passe (mettez PasswordAuthentication no en sshd_config , et soit mettre aussi UsePAM No ou désactiver l'authentification par mot de passe dans les paramètres PAM pour ssh). Une mesure intermédiaire consiste à restreindre les connexions ssh à une liste blanche d'utilisateurs avec AllowUsers ou AllowGroups en sshd_config .

Notez qu'autoriser les connexions par mot de passe n'est pas en soi un problème de sécurité. Les mots de passe faibles et les mots de passe espionnés sont les problèmes, et permettre l'authentification par mot de passe dans le serveur ssh est un catalyseur. Pour vous protéger contre l'espionnage de mot de passe, ne tapez jamais votre mot de passe sur une machine en laquelle vous n'avez pas entièrement confiance (mais si vous faites confiance à une machine, vous pouvez tout aussi bien y installer une clé privée, et vous n'aurez alors pas besoin d'authentification par mot de passe).

L'exigence minimale pour utiliser un client ssh sur une machine est que vous soyez sûr qu'il n'y aura pas de détournement actif de la communication ssh (une attaque de l'homme du milieu est possible si elle s'exécute sur la machine cliente - vous pensez vous tapez des commandes dans un client ssh vierge mais le client transmet en fait fidèlement vos données d'authentification mais insère également un cheval de Troie dans la communication par la suite). Il s'agit d'une exigence plus faible que de croire qu'il n'y aura pas de fouineur de mot de passe (généralement effectué via un enregistreur de frappe, mais il existe d'autres méthodes moins automatisées telles que le surf sur l'épaule). Si vous avez le minimum de confiance mais que vous craignez toujours les espions, vous pouvez utiliser des mots de passe à usage unique (OpenSSH les prend en charge via son support PAM).

Bien sûr, comme tout autre programme qui interagit avec des machines hors de votre contrôle (pas seulement des serveurs réseau mais aussi des clients), vous devez vous tenir au courant des mises à jour de sécurité.