🔒Sécurisation de base du serveur Debian.

Sécurisation et mise en place du serveur debain :

Ce que j’ai fait

1. Création d’un utilisateur non-root

Pourquoi ?

Le compte root, ayant les permissions absolues, représente une menace en cas de faille de sécurité.

J’ai donc créé un utilisateur avec les droits sudo, puis j’ai désactivé la connexion root.

# Créer un nouvelle utilisateur
adduser "user"

# Donne les permissions sudo a l'utilisateur
usermod -aG sudo "user" 

# affiche les groups d'un utilisateur
groups "user"

Une fois l’utilisateur créer je me connecte en ssh avec et je désactive la possibilité de se connecter avec root.

sudo nano /etc/ssh/sshd_config

-> PermitRootLogin no

2. Authentification par clé SSH Ed25519

J’ai remplacé l’authentification par mot de passe par une paire de clés SSH afin d’améliorer la sécurité et de mieux se protéger contre les bots.

Pourquoi est-ce plus sécurisé ?

Les bots tentent généralement des attaques par brute force en essayant des mots de passe.
Avec une clé Ed25519, la connexion nécessite :

Une phrase de passe (passphrase) qui protège la clé privée

La présence de la clé privée sur la machine cliente

La clé publique correspondante sur le serveur

# Générer la paire de clés dans POWERSHELL
ssh-keygen -t ed25519 -C "user@IP_SERVEUR" -f "$env:USERPROFILE\.ssh\id_ed25519_srv"

Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): ********
Your identification has been saved in C:\Users\"user"\.ssh\id_ed25519_srv
Your public key has been saved in C:\Users\"user"\.ssh\id_ed25519_srv.pub
The key fingerprint is:
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxx user@IP_SERVEUR

Deux clés sont alors générées :

Clé privée (à conserver sur sa machine) :

id_ed25519_srv

Clé publique (à copier sur le serveur) :

id_ed25519_srv.pub

Préparation du serveur :

# Création du dossier
mkdir -p /home/"user"/.ssh 

# Création du fichier qui aura les clés autorisé
touch /home/"user"/.ssh/authorized_keys

Une fois le répertoire préparé, j’envoie la clé publique sur le serveur.

# Envoyer la clé publique vers le serveur
scp "$env:USERPROFILE\.ssh\id_ed25519_srv.pub" "user"@IP_SERVEUR:/home/"user"/.ssh/uploaded_key.pub

# Ajouter la clé publique aux clés autorisées
cat /home/"user"/.ssh/uploaded_key.pub >> /home/"user"/.ssh/authorized_keys

# Supprimer le fichier temporaire
rm /home/"user"/.ssh/uploaded_key.pub

# Vérifier le contenu
cat /home/"user"/.ssh/authorized_keys

3. Modification de la configuration SSH

Pour l’instant, les changements n’ont pas encore d’impact sur la méthode de connexion.
Il faut modifier la configuration SSH pour la sécuriser davantage.

# Modifier la configuration
sudo nano /etc/ssh/sshd_config


J'ai modifié les lignes suivante :

# Changement du port ssh basique de 22 a 2222 car le port 22 est une cible privilégié 
Port 2222

# Connexion par mot de passe désactivé
PasswordAuthentication no

# Connexion par clé activé
PubkeyAuthentication yes

# Répertoire ou trouver les clés autorisé
AuthorizedKeysFile .ssh/authorized_keys

# Vérifier que la config SSH n'a pas de faute de syntaxe
sudo sshd -t

⚠️ C’est la partie critique.

Pour appliquer les modifications, il faut redémarrer le service SSH.
En cas d’erreur de configuration, la connexion SSH pourrait devenir inutilisable.

Démarche a suivre :

Fermer le premier terminal uniquement si la connexion fonctionne

Garder le premier terminal ouvert

Redémarrer le service SSH

Tester la connexion depuis un second terminal

# Redémarrer le service SSH
sudo systemctl restart sshd

# Dans un nouveau terminal ⚠️
ssh -i "$env:USERPROFILE\.ssh\id_ed25519_srv" -p2222 "user"@IP_SERVEUR

Cette fois-ci, une phrase de passe est demandée (et non plus un mot de passe).

4. Pour aller plus loin.

# Tentative de connexion en root
ssh -p2222 root@IP_SERVEUR

# Forcer la connexion par mot de passe
ssh -p2222 -o PubkeyAuthentication=no "user"@IP_SERVEUR