Sécuriser le serveur dans la première heure

Le VPS répond sur le port 22 à tout internet, en debian, avec un sudo sans mot de passe. Cette page te fait passer sur ton propre compte, met SSH sur son propre port avec des clés uniquement, allume un pare-feu, bannit le brute force et fait s'installer seules les mises à jour de sécurité. L'ordre compte : chaque nouvelle porte est testée depuis un second terminal avant de fermer l'ancienne.

Avant de commencer

Vérifie que la connexion livrée marche et que debian a sudo sans mot de passe, puis connecte-toi en debian dans un premier terminal et restes-y : un second terminal sur ton portable teste chaque changement depuis l'extérieur.

Deux terminaux, et le badge de chaque bloc dit lequel :

• Terminal A, badge serveur · debian : ta première session, ouverte maintenant. C'est ta bouée : ne la ferme pas avant que la page te le dise. Toutes les commandes sudo jusqu'à la bascule s'y tapent.
• Terminal B, badge Mac : un terminal sur ton portable, pour les tests depuis l'extérieur.

ops ne prend la main qu'une fois la nouvelle porte testée (une troisième session, ssh vps). La clé du serveur est celle créée à la page 2, ~/.ssh/id_ed25519_vps.

$ssh -i ~/.ssh/id_ed25519_vps -o IdentitiesOnly=yes debian@203.0.113.10 sudo -n true && echo OK

OK

Tout mettre à jour

Mets à jour, puis redémarre si Debian a laissé le fichier témoin qui dit qu'une mise à jour l'exige (un nouveau noyau, en général), et reconnecte-toi en debian :

$sudo apt update && sudo apt full-upgrade -y
$sudo apt install -y vim
$[ -f /var/run/reboot-required ] && sudo reboot

Nom et horloge

Donne son nom au serveur, empêche cloud-init de remettre celui d'OVH, et règle le fuseau horaire. timedatectl doit ensuite afficher ton fuseau et System clock synchronized: yes.

$sudo hostnamectl set-hostname web1
$printf 'preserve_hostname: true\nmanage_etc_hosts: false\n' | sudo tee /etc/cloud/cloud.cfg.d/99-hostname.cfg
$sudo sed -i '/^127\.0\.1\.1[[:space:]]/d' /etc/hosts
$echo "127.0.1.1 web1" | sudo tee -a /etc/hosts
$sudo timedatectl set-timezone Europe/Paris
$timedatectl

Ton propre utilisateur

Crée ops, dans le terminal A. adduser demande le mot de passe deux fois : tape celui rangé dans ton gestionnaire de mots de passe. Colle cette commande seule :

$sudo adduser --gecos "" ops

Puis mets-le dans sudo et sshusers, et écris ta clé publique (la valeur du panneau, pas une copie du fichier de debian) dans son authorized_keys :

$sudo groupadd -f sshusers
$sudo usermod -aG sudo,sshusers ops
$sudo install -d -m 700 -o ops -g ops /home/ops/.ssh
$echo '${SSH_PUBKEY}' | sudo tee /home/ops/.ssh/authorized_keys >/dev/null
$sudo chown ops:ops /home/ops/.ssh/authorized_keys
$sudo chmod 600 /home/ops/.ssh/authorized_keys

Vérifie la clé avant d'aller plus loin : le fichier doit contenir une clé Ed25519 valide.

$sudo ssh-keygen -lf /home/ops/.ssh/authorized_keys | grep -o '(ED25519)'

(ED25519)

Depuis le terminal B (Mac), connecte-toi avec le nouvel utilisateur par la clé seulement (encore sur le port 22) et lis ses groupes. Les options interdisent le mot de passe : si ça passe, la clé marche.

$ssh -i ~/.ssh/id_ed25519_vps -o IdentitiesOnly=yes -o PasswordAuthentication=no -o BatchMode=yes ops@203.0.113.10 'id -nG | grep -qw sudo && id -nG | grep -qw sshusers && echo groups OK'

groups OK

Durcir SSH

Écris le fichier complémentaire : copie la commande et colle-la dans le terminal A.

Port 1234
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowGroups sshusers

Teste la syntaxe, puis lis les valeurs effectives. sshd -t n'affiche rien quand la syntaxe est bonne ; la seconde commande doit afficher une seule ligne port, avec 1234, no pour les trois réglages suivants, et allowgroups sshusers.

$sudo sshd -t
$sudo sshd -T | grep -Ei '^(port|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|allowgroups) '

Pare-feu et bascule

Installe ufw, refuse tout en entrée, et ouvre le nouveau port et le 22 pour l'instant. ufw enable prévient qu'il peut perturber les connexions SSH ; réponds y. Le 22 reste ouvert pour que la session dans laquelle tu tapes survive, et pour qu'un retour arrière (supprimer le fichier complémentaire, redémarrer) te ramène sur un port que le pare-feu accepte.

$sudo apt install -y ufw
$sudo ufw default deny incoming && sudo ufw default allow outgoing
$sudo ufw allow 1234/tcp && sudo ufw allow 22/tcp
$sudo ufw enable

Avant le redémarrage, donne à ton portable le raccourci vps, avec la clé du serveur, dans le terminal B. Si ~/.ssh/config contient déjà un bloc Host vps, n'en ajoute pas un second : modifie-le avec ${EDITOR} ~/.ssh/config pour qu'il ait les mêmes lignes (ssh prend la première correspondance).

$touch ~/.ssh/config && chmod 600 ~/.ssh/config
$grep -q '^Host vps$' ~/.ssh/config || printf '\nHost vps\n  HostName 203.0.113.10\n  Port 1234\n  User ops\n  IdentityFile ~/.ssh/id_ed25519_vps\n  IdentitiesOnly yes\n  AddKeysToAgent yes\n  UseKeychain yes\n' >> ~/.ssh/config

$sudo systemctl restart ssh

Dans le terminal B, teste la nouvelle porte avec le raccourci. ssh redemande de confirmer la clé d'hôte : c'est la même clé, rangée sous un nouveau nom ([IP]:port), donc réponds yes.

$ssh -o BatchMode=yes vps echo connected

connected

Le nouveau port marche : ferme le 22, dans le terminal A.

$sudo ufw delete allow 22/tcp

Retirer le compte debian

Ouvre ta propre session depuis le Mac et vérifie que sudo accepte ton mot de passe :

$ssh vps

$sudo true && echo SUDO OK

Une fois SUDO OK revenu, ferme le terminal A (exit). Puis, dans la session ssh vps. userdel affiche mail spool (/var/mail/debian) not found : c'est normal.

$sudo pkill -KILL -u debian
$sudo userdel -r debian
$sudo rm -f /etc/sudoers.d/90-cloud-init-users

Depuis ton portable, vérifie que debian est refusé ; la réponse doit se terminer par Permission denied (publickey).

$ssh -p 1234 -o BatchMode=yes debian@203.0.113.10 true

Bannir le brute force

Avec les mots de passe refusés, deviner ne sert à rien, mais les robots frappent quand même. fail2ban lit le journal de SSH et bannit une adresse après trois échecs.

$sudo apt install -y fail2ban python3-systemd

Puis la prison, en un seul fichier :

[DEFAULT]
bantime.increment = true
[sshd]
enabled = true
port = 1234
backend = systemd
maxretry = 3
findtime = 10m
bantime = 1h

$sudo systemctl enable fail2ban && sudo systemctl restart fail2ban

$sudo fail2ban-client status sshd | head -1

Status for the jail: sshd

$sudo fail2ban-client set sshd unbanip ${MY_IP}

Mises à jour de sécurité automatiques

$sudo apt install -y unattended-upgrades apt-listchanges
$printf 'APT::Periodic::Update-Package-Lists "1";\nAPT::Periodic::Unattended-Upgrade "1";\n' | sudo tee /etc/apt/apt.conf.d/20auto-upgrades

Autorise un redémarrage à 04:30 quand une mise à jour en a besoin :

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:30";

$apt-config shell UU APT::Periodic::Unattended-Upgrade

UU='1'

Vérifier l'IPv6

La page suivante publie l'adresse IPv6 dans le DNS ; une adresse morte envoie les visiteurs IPv6 dans des délais d'attente. Sur le serveur, l'adresse globale doit être 2001:db8::10 et doit atteindre internet :

$ip -6 addr show scope global
$ping -6 -c 3 2001:4860:4860::8888

Note le résultat : si ping -6 répond, la page 4 publie l'adresse IPv6 (enregistrement AAAA) ; sinon, elle n'en publie pas.

Faire un snapshot de l'état propre (facultatif, payant)

Dans l'espace client OVH, ouvre ton VPS : sur son onglet d'accueil, l'option Snapshot propose de la commander ; une fois active, prends un snapshot au même endroit. Sans l'option, tu as quand même la sauvegarde automatique incluse (un jour de rétention). Les libellés des menus bougent : le guide OVH « Utiliser les snapshots sur un VPS » sur docs.ovhcloud.com donne le chemin actuel.

Terminé

Désormais, tu te connectes avec ssh vps. Page suivante : Pointer le domaine vers le serveur (DNS Infomaniak). Elle publie 203.0.113.10 et 2001:db8::10 dans la zone DNS Infomaniak de example.com, pour que le nom mène à cette machine avant que Caddy ne demande un certificat.