Comment sécuriser votre connexion SSH dans CentOS 7

SSH est le principal protocole utilisé pour se connecter aux serveurs Linux et les administrer. Pour cette raison, c’est l’un des ports les plus fréquemment attaqués lorsque des acteurs malveillants tentent d’accéder à votre serveur. Dans cet article, nous allons aborder quelques méthodes que vous pouvez utiliser pour rendre votre connexion SSH plus sûre.

Note : Selon le produit que vous avez avec OVHcloud, certaines de ces étapes peuvent avoir déjà été effectuées. Si c’est le cas, passez simplement à l’étape suivante. De plus, les étapes de cet article supposent que vous vous authentifiez auprès de votre serveur en utilisant des clés SSH. Si vous utilisez plutôt un mot de passe, certaines étapes de cet article ne fonctionneront pas.

Prérequis

  • Comment utiliser les clés SSH
  • Serveur exécutant CentOS 7

Thèmes

  • Création d’un nouvel utilisateur Sudo
  • Changer le démon SSH. Configuration

Création d’un nouvel utilisateur Sudo

C’est toujours la meilleure pratique d’interdire l’authentification root sur SSH puisque c’est le nom d’utilisateur que les gens vont essayer de pirater le plus. Ainsi, la première chose que nous voulons faire pour sécuriser notre serveur est de créer un nouvel utilisateur sudo pour SSH. Pour ce faire, entrez la commande suivante, en remplaçant le nom d’utilisateur rouge par le nom d’utilisateur de votre choix :

# adduser username

Puis, nous allons définir un mot de passe pour l’utilisateur :

# passwd username

Suivez l’invite pour créer et confirmer le mot de passe. Maintenant, nous voulons donner à notre nouvel utilisateur les privilèges sudo afin que nous puissions devenir root et exécuter les commandes qui nécessitent des privilèges administratifs. Nous pouvons le faire en entrant la commande suivante.

# usermod -aG wheel username

Enfin, nous voulons permettre à notre nouvel utilisateur de s’authentifier en utilisant la clé publique SSH que nous avons déjà fournie à l’utilisateur root. Nous pouvons utiliser une simple commande rsync pour copier la clé publique dans le fichier authorized_keys de notre nouvel utilisateur.

# rsync --archive --chown=username:username ~/.ssh /home/username

Avant de passer à l’étape suivante, déconnectez-vous et assurez-vous que vous êtes en mesure de vous authentifier sur le serveur en tant que nouvel utilisateur en utilisant SSH. Si vous ne pouvez pas vous connecter en tant que votre nouvel utilisateur, vous pourrez toujours vous connecter en tant que root ; confirmez que toutes les commandes ont été entrées correctement et essayez de vous connecter à nouveau en tant que votre nouvel utilisateur.

Modification de la configuration du démon SSH

Puisque nous utilisons des clés SSH et un nouvel utilisateur pour nous authentifier sur notre serveur, nous ne voulons jamais que quelqu’un s’authentifie en utilisant un mot de passe ou le nom d’utilisateur root. Pour accomplir ceci, nous voulons d’abord naviguer vers le fichier de configuration du démon OpenSSH. Pour ce faire, ouvrez le fichier dans un éditeur de texte de votre choix en utilisant la commande suivante:

$ sudo vi /etc/ssh/sshd_config

Il y a trois changements que nous voulons faire à ce fichier. Premièrement, nous voulons changer le port sur lequel OpenSSH écoute les requêtes.

Avertissement : Si vous avez des pare-feu actifs, vous devrez autoriser le trafic à travers le port que vous choisissez ou vous vous bloquerez hors de votre serveur. Si vous vous bloquez hors de votre serveur, vous pouvez retrouver l’accès par le biais de l’IPMI ou de KVM. Pour en savoir plus, veuillez consulter notre article Getting Started with IPMI.

En haut du fichier, vous verrez une section qui ressemble à ceci par défaut :

#Port 22#AddressFamily any#ListenAddress 0.0.0.0#ListenAddress ::

Décomplétez la section « Port » et choisissez n’importe quel numéro de port valide comme dans l’exemple suivant. Dans notre exemple, nous utilisons le port 12345.

Port 12345#AddressFamily any#ListenAddress 0.0.0.0#ListenAddress ::

Défilez ensuite jusqu’à la partie # Authentication: du fichier. Vous verrez cinq options qui apparaîtront comme suit par défaut:

#LoginGraceTime 2m#PermitRootLogin yes
PermitRootLogin yes#StrictModes#MaxAuthTries 6#MaxSessions 10

Ici, nous voulons changer le « oui » à côté de « PermitRootLogin » en « non ». Il apparaîtra comme suit:

#LoginGraceTime 2m
#PermitRootLogin yesPermitRootLogin no#StrictModes#MaxAuthTries 6#MaxSessions 10

Maintenant, nous voulons faire défiler le fichier sshd_config un peu plus loin pour effectuer notre dernière modification – désactiver l’authentification par mot de passe. Vous verrez une section qui ressemble à ceci par défaut:

# To disable tunneled clear text passwords, change to no here!#PasswordAuthentication yes#PermitEmptyPasswords no
PasswordAuthentication yes

Nous voulons changer le « yes » à côté de « PasswordAuthentication » en un « no ». Il apparaîtra comme suit:

# To disable tunneled clear text passwords, change to no here!#PasswordAuthentication yes#PermitEmptyPasswords no
PasswordAuthentication no

Sauvegarder et quitter le fichier. Enfin, nous devons redémarrer OpenSSH pour que les changements soient pris en compte. Faites-le en entrant la commande suivante:

$ sudo systemctl restart sshd.service

Prenons une seconde pour revoir ce que nous avons fait ici. Nous avons changé le numéro de port que nous utilisons pour écouter les requêtes SSH. Ensuite, nous avons désactivé l’accès SSH pour l’utilisateur root ou tout utilisateur essayant de s’authentifier avec un mot de passe. Si nous avons fait cela correctement, la commande suivante ne fonctionnera plus pour se connecter au serveur.

$ ssh [email protected]

Pour se connecter maintenant, nous allons devoir spécifier le numéro de port que nous utilisons pour écouter les requêtes SSH. Cela signifie qu’à partir de maintenant, nous devrons utiliser la commande suivante, en remplaçant le nombre à côté de « -p » par le numéro de port que nous avons choisi précédemment :

$ ssh -p 12345 [email protected]

Vérifiez que cette commande fonctionne et que la précédente ne fonctionne pas. Si c’est le cas, vous êtes prêt à accéder à votre serveur de manière sécurisée via SSH.

Conclusion

Avec autant de mauvais acteurs utilisant Internet, il n’a jamais été aussi important de sécuriser tous les points d’entrée potentiels vers votre serveur. En suivant ce guide, vous avez aidé à la sécurité du point d’entrée le plus commun sur les serveurs Linux.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.