FAQ #1967
Artikel editieren
Artikel weiterleiten

Comment puis-je protéger le service SSH sur mon serveur Linux ?

Cet article va s'attacher à décrire comment protéger le service SSH sur votre serveur Linux, grâce à l'exemple du serveur OpenSSH.

Nous recommandons à tous nos clients qui exploitent un V-Power Server, un serveur dédié ou un multiserveur de STRATO de configurer le service SSH. Ceci peut être effectué en suivant les trois étapes suivantes, bien que la dernière soit facultative.

Table des matières

1 Créer un nouvel utilisateur
2 Interdire la connexion à l'utilisateur root

3 Autoriser la connexion seulement via l'authentification de la clé publique

3.1 Installation d'une clé publique SSH avec le client Open SSH (Linux, MacOS X)
3.2 Installation d'une clé publique SSH avec PuTTY (Windows)

1 Créer un nouvel utilisateur

Il s'avère nécessaire de créer sur le système un nouvel utilisateur avant que la connexion de l'utilisateur root soit interdite.

Nous vous recommandons, pour ce faire, la démarche suivante :

Créer un nouvel utilisateur appartenant au groupe « users » et ayant un répertoire personnel dans /home :

useradd -g users -d /home/[nom d'utilisateur] -s /bin/bash [nom d'utilisateur]

Veuillez remplacer le [nom d'utilisateur] par un nom de votre choix (sans accent ni espace).

Attribuez un mot de passe pour le nouvel utilisateur :

passwd [nom d'utilisateur]

Le répertoire personnel du nouvel utilisateur est à créer manuellement comme utilisateur root :

mkdir /home/[nom d'utilisateur]

Le nouveau répertoire doit être affecté au nouvel utilisateur :

chown [nom d'utilisateur]:users /home/[nom d'utilisateur]/

Avant de passer à l'étape suivante, il s'avère judicieux de vérifier si une connexion SSH est aussi possible avec les nouvelles données de l'utilisateur.


Attendez de vous être connecté(e) avec succès pour passer à la prochaine étape.

2 Interdire la connexion à l'utilisateur root

Après avoir créé au cours de la première étape un nouvel utilisateur, il s'avère pertinent de désactiver complètement la connexion à l'utilisateur root.

Si votre serveur dispose d'une console série, la connexion reste bien évidemment possible en tant qu'utilisateur root.
Comment puis-je me connecter à mon serveur dédié par le biais de la console à distance ?

Nous vous recommandons la démarche suivante :

Veuillez changer dans le fichier /etc/ssh/sshd_config la ligne

PermitRootLogin yes

par

PermitRootLogin no

Il est désormais nécessaire de lire de nouveau les fichiers de configuration du service :

/etc/init.d/ssh reload (Debian/Ubuntu)
/etc/init.d/sshd reload (SUSE)

Il n'est désormais plus possible de se connecter sur le serveur en tant qu'utilisateur root via SSH. Veuillez pour ce faire utiliser le nouveau nom d'utilisateur créé ainsi que le mot de passe adéquat. Une fois que vous vous êtes connecté(e) avec succès, veuillez utiliser la commande su -l pour lancer un shell avec une autre identité. Si vous n'entrez aucun nom d'utilisateur, l'utilisateur root va être choisi par défaut et vous allez être prié(e) de saisir le mot de passe root.


Une fois le mot de passe entré correctement, vous pouvez continuer à travailler comme vous en avez l'habitude en tant qu'administrateur (root).

3 Autoriser la connexion seulement via l'autorisation de la clé publique
Une autre modification de votre configuration, qui permet de protéger encore plus efficacement votre serveur contre les tentatives d'effraction du SSH, est le passage complet à la procédure d'authentification par clé publique. La présence d'un fichier de clé sur l'ordinateur est impérative pour l'authentification de l'utilisateur qui souhaite se connecter sur votre serveur. Lors d'une connexion SSH, il n'est alors plus possible de s'authentifier au moyen de la saisie d'un mot de passe.

Vous devez bien évidemment faire très attention à la conservation de votre clé publique. Nous vous recommandons par ex., pour ce faire, de la conserver dans un conteneur crypté ou sur un support de données externe (clé USB). Il est également fortement conseillé de procéder à une copie de sauvegarde à un endroit approprié.

Nous vous recommandons la procédure générale suivante :

· Vous créez la paire de clés nécessaire (clé privée et publique)

· Vous créez dans le répertoire personnel de [nom d'utilisateur] un répertoire nommé .ssh pour la clé publique

· Vous chargez la clé publique sur le serveur dans le nouveau répertoire

· Vous autorisez en plus l'authentification de la clé publique

· Vous testez la fonctionnalité de l'authentification de la clé publique

· Vous passez complètement du service SSH à l'authentification par clé publique.

3.1 Génération des clés sur un système Linux ou Mac OS X

3.1.1 Génération des clés grâce à la commande suivante sur l'ordinateur local :

ssh-keygen -t dsa

Ce processus permet de créer deux fichiers de clé :

Your identification has been saved in /home/[nutzername]/.ssh/id_dsa

Your public key has been saved in /home/[nutzername]/.ssh/id_dsa.pub

3.1.2 Chargement de la clé publique sur le serveur cible à l'aide de SecureCopy
La saisie suivante vous permet de télécharger d'un ordinateur Linux ou MacOS X le fichier de la clé (id_dsa.pub) sous le nouveau nom de fichier authorized_keys dans le répertoire .ssh/ du nouvel utilisateur :

scp ~/.ssh/id_dsa.pub [nom d'utilisateur]@votrenomdeserveur.tld:.ssh/authorized_keys

Il est, pour ce faire, nécessaire que le répertoire existe déjà sur le serveur cible ~/.ssh/.

3.1.3 Vérifier si l'authentification de la clé publique est déjà autorisée sur le serveur cible ou éventuellement l'installer
Nous vous recommandons la démarche suivante :

Veuillez éventuellement changer dans le fichier /etc/ssh/sshd_config la ligne

PubkeyAuthentication no

par

PubkeyAuthentication yes

Il est désormais nécessaire de lire de nouveau les fichiers de configuration du service :

/etc/init.d/ssh reload (Debian/Ubuntu)
/etc/init.d/sshd reload (SUSE)

3.1.4 Il faut à présent vérifier que l'authentification par clé publique fonctionne aussi
La saisie suivante vous permet de monter une connexion SSH vers votre serveur depuis un ordinateur Linux ou MacOS X. Indiquez votre clé privée et vous serez seulement prié(e) d'entrer le mot de passe de votre fichier de clé local :

ssh -i ~/.ssh/id_dsa -l [nom d'utilisateur] Votre_nomdeserveur.tld

3.1.5 Une fois la connexion réussie, vous pouvez passer complètement à la procédure d'authentification par clé publique.
Nous vous recommandons la procédure générale suivante :

Veuillez éventuellement changer dans le fichier /etc/ssh/sshd_config la ligne

PasswordAuthentication yes

par

PasswordAuthentication no

et la ligne

ChallengeResponseAuthentication yes

par

ChallengeResponseAuthentication no

Il est à présent nécessaire de lire de nouveau les fichiers de configuration du service :

/etc/init.d/ssh reload (Debian/Ubuntu)
/etc/init.d/sshd reload (SUSE)

3.2 Génération des clés sur un système Windows

3.2.1 Génération des clés

Sous Windows, la gestion des clés se fait grâce à l'outil Puttygen. Vous pouvez le télécharger sur le site Internet de Putty :
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.

Pour créer une clé, il vous faut choisir le type de clé (en règle générale SSH2, RSA ou DSA), inscrire sa longueur en bits, puis cliquer sur le bouton Generate. Par le biais des mouvements de la souris, des valeurs de hasard sont recueillies, cela signifie que la « barre de génération » ne se remplit que lorsque vous bougez la souris.

Une fois la clé créée, veuillez inscrire dans le champ Key passphrase un mot de passe personnel à confirmer dans le champ Confirm passphrase.



Les autres étapes correspondent à la manière de procéder décrite aux points 3.1.3 à 3.1.5. Pour charger la clé publique dans le répertoire ~/.ssh/, nous vous recommandons le programme WinSCP que vous pouvez télécharger à cette adresse http://winscp.net/eng/docs/lang

Si vous optez pour WinSCP, vous allez être prié(e), lors de votre première connexion à votre serveur, d'accepter ou de refuser une clé d'authentification. Veuillez accepter cette clé. Votre client local saura ainsi, lors de vos prochaines connexions, que votre serveur est véritablement votre serveur et pas un autre.

×