Part 2 Guide sur l’installation d’un serveur sous Debian 7 (Wheezy)

[dokuro]

Guide Debian 7 (partie 2/8) : sécuriser l’accès SSH

 

Introduction

 

 

De la même façon que vous ne laissez pas la porte ouverte en sortant de chez vous, la porte d’entrée de votre serveur, c’est-à-dire l’accès SSH, requiert un minimum de sécurisation.

Modifier le mot de passe root

En général, après la commande d’un serveur dédié ou virtuel, votre prestataire vous transmettra les informations de connexion par mail, en y joignant le mot de passe du compte root. Il est important de changer celui-ci immédiatement dès votre première connexion.

Pour cela, lancez la commande suivante en root :

 

1

passwd

Je ne vous ferai pas l’affront de vous expliquer pourquoi un mot de passe suffisamment complexe pour ne pas être trouvé pas une attaque de type bruteforce ou dictionnaire est très largement souhaitable 

Ajout d’un nouvel utilisateur

Pour la suite, et pour des raisons de sécurité évidentes, nous n’utiliserons pas le compte root pour les connexions à distance. C’est pourquoi nous allons créer un groupe contenant des utilisateurs qui seront autorisés à se connecter via SSH.

 

1

groupadd sshusers

On créé ensuite un nouvel utilisateur puis on l’ajoute au groupe qui sera autorisé à se connecter via SSH.

 

 

useradd -m homer

passwd homer

usermod -a -G sshusers homer

 

Configuration de ssh

 

 

1

vim /etc/ssh/sshd_config

On commence par changer le port par défaut :

 

1

Port 2222

Note : Vous pouvez utiliser n’importe quel port, pour peu que celui-ci ne soit pas réservé par un autre service. Avoir un port non standard vous permettra d’éviter une partie des attaques automatisées que l’on rencontre chez certains prestataires . Et comme j’entends déjà les experts hurler, je précise que oui, l’obscurantisme n’est en aucun cas un gage de sécurité. Toutefois, je peux vous assurer qu’un simple changement de port sur une dedibox permet de souffler un peu au niveau des tentatives de bruteforce SSH (les IP des machines sont connues et les scripts kiddies s’en donnent à coeur joie). Pour conclure, n’oubliez jamais qu’un attaquant qui se focalisera sur votre serveur n’aura aucun mal à déterminer sur quel port tourne le daemon SSH.

Le compte root n’est pas autorisé à se connecter directement depuis SSH :

 

1

PermitRootLogin no

Seul les utilisateurs appartenant au groupe sshusers sont autorisés à se connecter (il faut ajouter cette ligne) :

 

1

AllowGroups sshusers

on vérifie que la version 2 du protocole est utilisée :

 

1

Protocol 2

On redémarre le daemon SSH :

 

1

/etc/init.d/ssh restart

À ce stade, ne surtout pas fermer l’ancienne connexion, au risque de ne plus pouvoir se reconnecter par la suite. Ce que je vous conseille, c’est d’ouvrir un nouvel onglet dans votre terminal et de tester la connexion avec le port et l’utilisateur adéquat.

Authentification par un système de clé publique/clé privée

L’authentification par clé publique/privée se révèle pratique dans le cas où vous souhaitez ne pas avoir à taper le mot de passe à chaque connexion.

Cette technique permet de renforcer la sécurité, car elle demande à l’utilisateur d’être en possession de deux informations pour se connecter au serveur (une clé privée et le mot de passe de cette clé).

Je ne détaillerai pas ici le fonctionnement du protocole, sachez juste que nous allons avoir besoin de deux choses :

• une clé privée, que l’on gardera précieusement sur notre ordinateur, dans le dossier .ssh de notre répertoire personnel
• une clé publique, que l’on enverra dans le dossier .ssh de l’utilisateur sur le serveur

Pour générer tout ça, rien de plus simple, il suffit de lancer la commande suivante sur votre ordinateur .

 

1

ssh-keygen -t rsa

Répondre aux questions :

 

1

2

3

Enter file in which to save the key (/Users/votre_user/.ssh/id_rsa): faire entrée

 

Enter passphrase (empty for no passphrase): choisir un mot de passe qui protègera la clé

La phrase de passe (ou passphrase) sert en fait à décrypter votre clé privée. Il est possible de ne pas en mettre, mais dans ce cas, une personne qui mettrait la main sur votre clé privée serait tout à fait apte à se connecter au serveur. Bref, il serait idiot de se priver d’une protection supplémentaire, donc choisissez un mot de passe avec soin.

Il faut maintenant copier la clé publique dans le répertoire .ssh de votre utilisateur (celui avec lequel vous vous connectez sur le serveur) :

Pour cela, lancer la commande suivante depuis votre ordinateur :

 

1

ssh <user>@<ip_du_serveur> -p <port> "echo $(cat ~/.ssh/id_rsa.pub) >> .ssh/authorized_keys"

Note : il se peut que le répertoire .ssh n’existe pas dans le home de votre utilisateur sur le serveur. Il suffit de se connecter sur celui-ci et de le créer :

 

cd

mkdir .ssh

touch .ssh/authorized_keys

Si tout s’est bien passé, vous devriez être en mesure de vous connecter au serveur en utilisant le système de clé. À la première connexion, le mot de passe servant à décrypter la clé privée vous sera demandé. Sur OSX, le système vous proposera de l’enregistrer dans le trousseau d’accès. Sous un système Linux, il est possible qu’il en fasse de même (sinon, utilisez ssh-agent pour ne pas avoir à retaper ce mot de passe).

Si vous le souhaitez, vous pouvez aussi utiliser uniquement le système de clés pour vous connecter au serveur en passant le paramètre PasswordAuthentication sur no dans le fichier /etc/ssh/sshd_config. De ce fait, seule une personne possédant la clé privée et son mot de passe sera apte à se connecter. Cependant, si jamais vous perdez cette clé, vous serez incapable de vous connecter par la suite. Faites donc attention si vous optez pour cette solution

Rendez-vous demain pour la troisième partie de ce guide qui portera sur l’envoi de mail depuis votre serveur