Sécuriser un VPS avant d'y installer des agents IA

TL;DR

Avant d'installer le moindre agent IA sur mon VPS, je l'ai durci : mise à jour du système, connexion SSH par clé uniquement, pare-feu UFW en tout-refuser-sauf-l'essentiel, VPN Tailscale pour ne plus exposer SSH publiquement, et un filet de sécurité (clé de secours, console KVM) au cas où je me verrouillerais moi-même dehors. Un agent capable d'exécuter des commandes augmente fortement l'enjeu du hardening : ce n'est plus seulement moi qui peux me tromper.

Sommaire

Pourquoi durcir avant d'installer quoi que ce soit
Mettre le système à jour
SSH par clé, plus rien d'autre
Le pare-feu : tout refuser, autoriser l'essentiel
Le filet de sécurité
Tailscale : fermer SSH au public

Pourquoi durcir avant d'installer quoi que ce soit

L'ordre compte. J'ai durci le VPS avant d'y installer Docker, Ollama ou le moindre agent, pas après. Un agent IA qui peut exécuter des commandes shell n'est plus un simple outil qu'on utilise : c'est un processus qui a potentiellement les mêmes droits que moi sur la machine. Une mauvaise configuration réseau ou un compte root accessible par mot de passe, c'est déjà risqué avec un seul humain aux commandes. Avec un agent capable d'agir seul, la marge d'erreur se réduit encore.

Rien de ce qui suit n'est spécifique à l'IA : ce sont les bases classiques de durcissement d'un serveur Ubuntu exposé sur Internet. Je les détaille parce qu'elles deviennent, je crois, un prérequis qu'on ne peut plus sauter dès qu'on parle d'agents autonomes.

Mettre le système à jour

La première commande, avant tout le reste :

sudo apt update && sudo apt upgrade -y

Rien de sophistiqué, mais un système à jour ferme une bonne partie des vulnérabilités connues avant même de toucher à la configuration.

SSH par clé, plus rien d'autre

Deux réglages dans /etc/ssh/sshd_config :

PermitRootLogin no
PasswordAuthentication no

L'ordre dans lequel on applique ça compte, et c'est l'erreur la plus facile à commettre : désactiver l'authentification par mot de passe avant d'avoir copié sa propre clé publique sur le serveur, et se retrouver enfermé dehors. J'ai donc fait dans cet ordre précis :

Générer une paire de clés en local si ce n'est pas déjà fait.
Copier la clé publique sur le VPS :
```
ssh-copy-id ubuntu@mon-vps
```
Se reconnecter une fois avec la clé pour vérifier que ça fonctionne, avant de toucher à quoi que ce soit d'autre.
Seulement à ce moment-là, éditer sshd_config et redémarrer le service :
```
sudo systemctl restart ssh
```

Si l'étape 3 est sautée et que la connexion par clé ne fonctionne pas, on se retrouve avec un VPS accessible uniquement par la console de secours de l'hébergeur (voir plus bas), le temps de corriger.

Le pare-feu : tout refuser, autoriser l'essentiel

UFW en politique « tout refuser en entrée, tout autoriser en sortie » :

sudo ufw default deny incoming
sudo ufw default allow outgoing

Là encore, un piège classique : activer UFW avant d'avoir explicitement autorisé le port SSH coupe l'accès dès la prochaine reconnexion, pas forcément la session en cours mais mieux vaut ne pas compter dessus. La règle SSH doit être ajoutée avant l'activation, pas après :

sudo ufw allow OpenSSH
sudo ufw enable

À ce stade, le VPS n'accepte plus que les connexions SSH entrantes, et laisse sortir librement le reste (mises à jour, appels vers des API, etc.).

Le filet de sécurité

Avant de toucher à quoi que ce soit d'autre, une question à se poser : que se passe-t-il si la prochaine règle de pare-feu me verrouille dehors ? Fermer l'accès public plus loin dans cet article, c'est se donner les moyens de se tromper gravement si une configuration part de travers. Deux filets, vérifiés avant, pas après :

une clé SSH de récupération, générée à part et stockée dans un gestionnaire de mots de passe sécurisé plutôt que sur le poste utilisé au quotidien, protégée par une passphrase comme n'importe quelle autre clé privée ;
la console KVM de l'hébergeur (OVH dans mon cas), qui donne un accès direct à la machine indépendamment du réseau, y compris si SSH et Tailscale sont tous les deux inaccessibles.

Je n'ai heureusement pas eu besoin d'utiliser l'un ou l'autre jusqu'ici, mais les avoir vérifiés et prêts avant de fermer quoi que ce soit change la nature du risque : une erreur de configuration redevient récupérable en quelques minutes plutôt qu'un aller-retour avec le support de l'hébergeur.

Tailscale : fermer SSH au public

Le filet de sécurité vérifié, l'étape suivante consiste à ne plus exposer SSH du tout sur l'IP publique. J'utilise Tailscale, un VPN qui crée un réseau privé entre mes machines (le « tailnet ») :

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Une fois connecté au tailnet et la connexion SSH via l'IP Tailscale vérifiée, je referme l'accès public :

sudo ufw allow in on tailscale0 to any port 22
sudo ufw delete allow OpenSSH

Le port 22 n'est alors plus joignable depuis Internet, seulement depuis le réseau privé Tailscale. Un scan de ports externe sur le VPS ne voit plus rien d'ouvert pour SSH.

Le VPS est maintenant accessible uniquement par clé, uniquement via Tailscale, avec un filet de sécurité vérifié. La suite : installer Docker, Ollama et Hermes sur cette base, et le premier piège qui n'était pas prévu au programme.