e-grisel.net

Serveur dédié – Configuration de SSH

Après avoir commandé le serveur dédié et reçu les codes d’accès, il y a plusieurs étapes à effectuer lors de la première connexion au serveur :

• Modifier le mot de passe root
• Créer un nouvel utilisateur
• Sécuriser SSH
• Faire une mise à jour du serveur
• Modifier les locales

Modifier le mot de passe root

La modification du mot de passe root s’effectue très simplement avec la ligne de code suivante :

[root@serveur:~]# passwd
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd: le mot de passe a été mis à jour avec succès

La commande est identique pour chaque utilisateur qui désire changer son mot de passe. Pour changer le mot de passe d’un utilisateur lorsqu’on est root, la commande est la suivante :

[root@serveur:~]# passwd user

ou user représente le login de l’utilisateur

Créer un nouvel utilisateur

Afin d’éviter d’avoir à se connecter au serveur en utilisant root, nous allons créer un nouvel utilisateur :

[root@serveur:~]# adduser --home /home/etienne etienne
Ajout de l'utilisateur "etienne"...
Ajout du nouveau groupe "etienne" (1000)...
Ajout du nouvel utilisateur "etienne" (1000) avec le groupe "etienne"...
Création du répertoire personnel "/home/etienne"...
Copie des fichiers depuis "/etc/skel"...
Entrez le nouveau mot de passe UNIX :
Retapez le nouveau mot de passe UNIX :
passwd : le mot de passe a été mis à jour avec succès
Modification des informations relatives à l'utilisateur etienne
Entrez la nouvelle valeur ou "Entrée" pour conserver la valeur proposée
Nom complet []: Etienne Grisel
N° de bureau []:
Téléphone professionnel []:
Téléphone personnel []:
Autre []:
Ces informations sont-elles correctes ? [O/n] O

Et voilà, c’est aussi simple que cela, nous pouvons passer à la suite.

Sécuriser SSH

Il faut savoir que lorsque vous vous connecter à votre serveur via SSH comme cela :
[etienne@home:~]$ ssh root@ip.de.mon.serveur vos données circulent en clair sur internet jusqu’à ce que vous ayez saisi votre mot de passe, ce qui n’est pas très sécurisé, c’est pourquoi nous allons utiliser le système des clés publiques afin que tout soit crypté dès le début. Et petit avantage supplémentaire, vous n’aurez plus à saisir votre mot de passe à chaque connexion.

Commençons par générer une clef locale sur votre ordinateur personnel (Linux) :
[etienne@home:~]$ ssh-keygen -t dsa et accepter la localisation proposée. Ensuite saisir une « passphrase », sorte de mot de passe sous forme de phrase. Vous aurez ainsi 2 fichiers créés, l’un contenant votre clef privée (/home/etienne/.ssh/id_dsa) et l’autre contenant votre clef publique (/home/etienne/.ssh/id_dsa.pub).

Il faut ensuite enregistrer votre clef publique sur le serveur afin qu’il puisse vous identifier
[etienne@home:~]$ scp ~/.ssh/id_dsa.pub etienne@ip.de.mon.serveur:~/ puis sur le serveur (copie la clé sur le serveur)
[etienne@serveur:~]$ cat id_dsa.pub >> ~/.ssh/authorized_keys (enregistre la clé)
[etienne@serveur:~]$ rm ~/id_dsa.pub (supprime le fichier que nous venons de transférer) et le tour est joué.

Pour éviter de devoir à chaque fois taper la totalité de votre adresse IP ou du nom de domaine, vous pouvez créer un alias. Pour ce faire créer un fichier « config » dans le dossier ~/.ssh/ de votre ordinateur local et ajoutez-y les données suivantes:
Host mon_alias
User votre_user_sur_le_serveur
HostName adresse_ip_du_serveur_ou_nom_du_serveur puis pour vous connecter
ssh mon_alias

Nous allons maintenant vérifier que le fichier de configuration de SSH (/etc/ssh/sshd_config) est configuré de manière sûre. Voici les données que nous devons, à mon humble avis, vérifier et éventuellement modifier :

Port 22
Il s’agit du port sur lequel nous nous connectons via SSH (par défaut 22). La logique voudrait qu’on le modifie afin d’éviter les attaques de force brute, mais en faisant ainsi nous ôtons toute possibilité à notre prestataire (OVH dans mon cas) de pouvoir nous dépanner en cas de besoin, je vous propose donc de le laisser tel quel.

Protocol 2
Il s’agit de la version du protocole SSH utilisée. Le protocole 1 ayant quelques failles de sécurité, il faut impérativement utiliser la version 2.

PermitRootLogin yes
Autorisons-nous root à se connecter directement en SSH ? En théorie non, car un pirate pourrait utiliser une attaque par dictionnaire pour tenter de se connecter en root sur notre serveur, mais pour les mêmes raisons que pour le choix du port, nous allons laisser l’accès à root. Une bonne utilisation du firewall (via Iptables) et de Fail2ban nous permettrons de limiter au maximum les risques.

RSAAuthentication yes
PubkeyAuthentication yes
Ces options nous permettent de nous connecter à l’aide d’une clef publique, comme nous l’avons vu précédemment. Je vous recommande chaudement de mettre ces options à yes.

PermitEmptyPasswords no
Voulons-nous autoriser l’accès à notre serveur SSH sans mot de passe ? Bien sûr que non, cela serait une énorme faille dans la sécurité de notre serveur ! Nous laissons donc la valeur à no.

PasswordAuthentication yes
Voulons-nous pouvoir nous connecter en utilisant un mot de passe (comme nous le faisions avant d’utiliser le système des clefs publiques) ? Normalement ce n’est plus nécessaire, à moins de devoir se connecter au serveur depuis un autre ordinateur que celui sur lequel vous avez généré la clef. Si ce n’est pas le cas, nous pouvons passer cette option à no (n’oubliez pas d’enlever le # au début de la ligne, sinon elle restera en commentaire et vos modifications ne seront pas prisent en compte). Nous reviendrons sur cette option dans un prochain article sur MySecureShell, mais pour l’instant mieux vaut rester prudent et empêcher qu’un pirate tente une attaque par dictionnaire.

Nous avons fait le tour des options qui me semblent importantes. Pour que le serveur SSH les prenne en compte, n’oublions pas de le redémarrer
[root@serveur:~]# /etc/init.d/ssh restart et de tester une connexion via un autre terminal que celui avec lequel nous sommes connectés afin de s’assurer que nous ne nous sommes pas auto-exclu de notre serveur.

Faire une mise à jour du serveur

Une chose très importante sur un serveur internet, tout comme sur chaque ordinateur, c’est de s’assurer que les logiciels que nous utilisons sont toujours à jour. Pour cela, sur Debian GNU/Linux ou toute autre distribution linux dérivée de Debian, on exécute la ligne de code suivante :
[root@serveur:~]# apt-get update && apt-get upgrade
Si des logiciels doivent être mis à jour, une liste vous sera proposée et vous n’aurez plus qu’à valider par une pression sur la touche [Enter] de votre clavier. N’oubliez pas d’effectuer cette opération régulièrement si vous ne voulez pas risquer une intrusion sur votre serveur.

Modifier les locales

Un problème que j’ai eu lors de mes premières connexions, c’est que tous les accents et caractères spéciaux étaient remplacés par un losange noir avec un point d’interrogation. Pour éviter cela, une petite commande toute simple et le tour est joué :
[root@serveur:~]# dpkg-reconfigure locales et dans la deuxième page on sélectionne par défaut l’option fr_FR.UTF-8 ou n’importe quelle option qui fini par UTF-8. Ensuite il ne nous reste plus qu’à nous déconnecter et nous reconnecter et le problème a disparu ! Magique n’est-ce pas ?

Prochaine étape : Mise en place du firewall
Etape précédente : Introduction