Sécuriser Proxmox : compte dédié, 2FA et pare-feu (partie 1)

Tu viens d’installer Proxmox VE 9, et si tu as suivi l’article précédent, tu as maintenant une interface d’administration qui tourne, accessible dans ton navigateur sur le port 8006. Tu t’y connectes avec root et le mot de passe choisi à l’installation. Ça marche, c’est satisfaisant, et c’est exactement là que la plupart des gens s’arrêtent.

Problème : root, c’est le passe-partout de tout le bâtiment. Il ouvre absolument toutes les portes — créer, détruire, reconfigurer, effacer. Or tu ne te balades pas avec le passe dans la poche du matin au soir juste pour ouvrir ton propre bureau. Tu prends ta clé perso pour le quotidien, et tu gardes le passe-partout au coffre, pour les urgences. Travailler en root toute la journée sur ton hyperviseur, c’est exactement l’inverse : se promener avec le passe en permanence. Et le jour où ce mot de passe fuite, est deviné, ou se retrouve dans une fuite de données quelconque, ce n’est pas une porte qui s’ouvre, c’est tout le bâtiment qui s’écroule — l’intégralité de tes machines virtuelles.

La bonne nouvelle : remettre le passe au coffre prend une session tranquille, et tout se fait nativement dans Proxmox, sans installer le moindre outil supplémentaire. Encore mieux : tout se passe dans l’interface web, celle que tu utilises déjà. Pas de ligne de commande obligatoire, pas de fichier de configuration à éditer à la main — on clique dans les menus, exactement comme tu l’as fait pour explorer Proxmox jusqu’ici. La ligne de commande n’apparaîtra qu’une seule fois, tout à la fin, comme filet de secours au cas où — et je t’expliquerai chaque commande.

À la fin de cet article, tu auras ta clé perso (un compte dédié), le passe-partout root rangé en sécurité, et plus personne n’accédera à ton interface sans ton compte et ton téléphone.

On va procéder dans cet ordre :

1. Créer un compte d’administration dédié — ta clé perso pour le quotidien.

2. Activer la double authentification (2FA) sur ce compte — et aussi sur root, le passe qu’on garde au coffre mais qu’on protège quand même.

3. Générer des clés de récupération, le filet qui t’évite de rester dehors si tu perds ton téléphone.

4. Activer le pare-feu intégré de Proxmox et poser une politique de base saine.

Un point d’honnêteté avant de commencer : on ne touche pas ici à la sécurité du système Debian sous-jacent (l’accès SSH au serveur lui-même). C’est un sujet à part entière, qui dépasse Proxmox, et qui aura son propre article. Aujourd’hui, on verrouille l’interface d’administration Proxmox. C’est la première marche, et la plus efficace.

1. Créer ton compte d’administration dédié

C’est ta clé perso. L’objectif : avoir un compte personnel avec lequel tu feras tout ton travail quotidien, pour ne plus jamais avoir à taper root.

Realm PAM ou realm Proxmox VE ?

Au moment de créer le compte, Proxmox va te demander un type d’authentification (realm). Deux choix t’intéressent :

• Linux PAM : le compte existe aussi sur le système Debian sous-jacent. Il peut donc se connecter en SSH au serveur, ouvrir un shell, etc.

• Proxmox VE authentication server : le compte n’existe que dans Proxmox. Il peut administrer l’hyperviseur via l’interface, mais il n’a aucun accès au système Debian en dessous.

Pour un compte d’administration de l’interface, on prend Proxmox VE authentication server. La raison est simple et cohérente avec tout le reste de la démarche : moins ce compte peut faire de choses en dehors de son rôle, moins il y a de surface à attaquer. Ce compte sert à piloter Proxmox depuis le navigateur, pas à ouvrir un Terminal — donc on ne lui donne pas la capacité d’ouvrir un shell. Les mots de passe de ce realm sont stockés à part par Proxmox, ils n’ont rien à voir avec les comptes du système.

Créer le compte

Dans l’interface, va dans Datacenter → Permissions → Users, puis clique sur Add.

Remplis :

• User name : le nom de ton compte (par exemple ton-prenom, ou ce que tu veux).

• Realm : sélectionne Proxmox VE authentication server.

• Password : un mot de passe long et unique. C’est ta clé perso, ne la réutilise nulle part ailleurs.

• Les autres champs (email, groupe, etc.) sont optionnels pour l’instant.

Valide.

Ton compte apparaît dans la liste, sous la forme ton-prenom@pve. Le @pve confirme qu’il vit dans le realm Proxmox VE.

À ce stade, le compte existe mais il ne peut rien faire. Créer un utilisateur et lui donner des droits sont deux opérations séparées dans Proxmox — c’est l’étape suivante.

Lui donner les droits d’administration

Va dans Datacenter → Permissions, clique sur Add, puis User Permission.

⚠️ Premier piège. Le bouton Add est un menu déroulant avec trois entrées : User Permission, Group Permission et API Token Permission. Il est très facile de cliquer sur la mauvaise. Choisis bien User Permission : une permission de groupe ne s’applique qu’aux membres du groupe, et si ton compte n’est dans aucun groupe, il n’héritera de rien.

Renseigne :

• Path : / — la racine. Ça signifie « partout, sur tout l’environnement ».

• User : ton compte ton-prenom@pve.

• Role : Administrator.

• Propagate : laisse coché (par défaut). C’est ce qui fait descendre les droits sur tout l’arbre en dessous de /.

⚠️ Deuxième piège, le plus sournois. Ne valide pas sans avoir rempli le champ Role. Une permission créée avec un Path et un User mais sans rôle est une coquille vide : elle apparaît bien dans la liste, mais elle ne donne aucun droit. Résultat : ton compte se connecte, mais le menu est réduit et tu ne peux rien faire — pas même créer une VM. Après validation, vérifie que la colonne Role de ta nouvelle ligne affiche bien Administrator.

Un mot sur le choix du rôle. Proxmox propose un rôle qui s’appelle PVEAdmin, et on pourrait croire que c’est celui qu’il faut. Sauf que PVEAdmin ne peut pas modifier les réglages système (gestion de l’alimentation, modification de la configuration, gestion des realms). Si tu veux que ton compte dédié remplace vraiment root pour ton usage quotidien — y compris configurer le réseau, gérer les sauvegardes, tout — c’est le rôle Administrator qu’il te faut, au chemin /. C’est ce qu’on fait ici.

Note — On accorde ici tous les droits à un seul compte, parce que tu es seul à administrer ton homelab. Dans un environnement à plusieurs personnes, on découperait les droits par rôle et par périmètre (un compte qui ne gère que les sauvegardes, un autre que telle VM, etc.). C’est tout l’intérêt du système de permissions de Proxmox — mais ce sera le sujet d’un autre article.

Tester immédiatement

C’est l’étape que personne ne fait et qui sauve des soirées. Avant d’aller plus loin, vérifie que ton nouveau compte perso fonctionne :

1. Déconnecte-toi (bouton Logout en haut à droite).

2. Reconnecte-toi, mais cette fois avec ton compte ton-prenom@pve et son mot de passe — pense à sélectionner le bon realm dans le menu déroulant de l’écran de connexion.

3. Vérifie que tu accèdes bien à tout, que tu vois tes VM, tes réglages, et que tu peux par exemple lancer une création de VM.

Si ça marche, tu as ta clé perso. On peut maintenant la renforcer avec la double authentification. Si ça ne marche pas, ne va surtout pas plus loin : reconnecte-toi en root et reprends les étapes ci-dessus, c’est qu’un droit n’a pas été correctement attribué (souvent le rôle oublié — le deuxième piège ci-dessus).

2. Activer la double authentification (2FA)

Ton nouveau compte a un mot de passe. Mais un mot de passe, ça se vole, ça fuite, ça se devine. La double authentification ajoute une seconde serrure : même si quelqu’un connaît ton mot de passe, il lui manque le code qui change toutes les 30 secondes sur ton téléphone. C’est l’une des couches de sécurité les plus efficaces que tu puisses ajouter.

On utilise la méthode TOTP (Time-based One-Time Password) : un code à 6 chiffres généré par une app sur ton téléphone, synchronisé dans le temps avec le serveur. Pas de SMS (vulnérable), pas de dépendance à un service tiers.

Choisir une app d’authentification

Il te faut une app TOTP sur ton téléphone. Pour rester cohérent avec la démarche souveraineté, privilégie une app open source :

• Aegis (Android) — open source, sauvegardes chiffrées que tu contrôles.

• Proton Authenticator (Android/iOS) — open source, de l’éditeur de Proton Mail, synchronisation chiffrée.

• ente Auth (Android/iOS) — open source, synchronisation chiffrée entre appareils.

Google Authenticator fonctionne aussi, mais une app open source dont tu maîtrises les sauvegardes est plus dans l’esprit du projet. Installe-la avant de continuer. Un article sera dédié à ce sujet.

Activer la 2FA sur ton compte dédié

Connecté avec ton compte ton-prenom@pve, va dans Datacenter → Permissions → Two Factor, puis clique sur Add → TOTP.

Une fenêtre s’ouvre avec un QR code :

• Description : un libellé pour reconnaître cette entrée (par exemple « Proxmox HMT — téléphone »).

• Le QR code : scanne-le avec ton app d’authentification. Elle va créer une entrée qui affiche un code à 6 chiffres renouvelé toutes les 30 secondes.

• Verify Code : tape le code à 6 chiffres affiché par ton app, pour prouver que la synchronisation fonctionne.

💡 Le QR code est un secret — voici pourquoi je le montre quand même. Ce QR code (et le champ Secret en clair à côté) encode la graine qui génère tes codes à 6 chiffres. Quiconque met la main dessus peut générer tes codes 2FA à volonté, et ta double authentification ne protège plus rien.

Si je l’affiche ici, c’est parce que toutes les captures de cet article sont faites sur une VM Proxmox de démonstration, montée exprès et détruite dès les captures terminées. Le secret que tu vois n’existe déjà plus.

Sur ton serveur réel, traite ce secret comme un mot de passe : ne le capture pas, ne le partage pas, ne le laisse pas traîner. Et si jamais il a été exposé (une capture envoyée à quelqu’un, par exemple), régénère-le : rouvre l’entrée TOTP, clique Randomize, re-scanne le nouveau QR dans ton app, et supprime l’ancienne entrée.

Valide.

À partir de maintenant, la 2FA est active sur ce compte : à la prochaine connexion, après le mot de passe, Proxmox te demandera le code.

⚠️ Ne te déconnecte pas encore. On génère d’abord les clés de récupération (section suivante), ton filet de secours si tu perds ton téléphone. Sinon, un téléphone perdu = un compte définitivement inaccessible.

Et root@pam ?

root est le passe-partout qu’on garde au coffre. On ne s’en sert plus au quotidien, mais il reste le compte de secours — et un compte de secours qui peut tout faire mérite lui aussi sa 2FA. La procédure est identique : connecte-toi en root, va dans Datacenter → Permissions → Two Factor, Add → TOTP, scanne, vérifie, valide. Fais-le après avoir validé que ton compte dédié + 2FA + clés de récupération fonctionne de bout en bout, pour ne pas verrouiller les deux comptes d’un coup en cas de souci.

Note — La 2FA mérite à elle seule un article complet : enforcement au niveau du realm (rendre la 2FA obligatoire pour tous les comptes), clés matérielles WebAuthn (YubiKey, passkeys), gestion fine de la récupération. On y reviendra. Ici, on pose l’essentiel : TOTP sur tes deux comptes, c’est déjà l’immense majorité du bénéfice.

3. Générer tes clés de récupération

Tu as maintenant une 2FA active. Pose-toi la vraie question : que se passe-t-il si tu perds ton téléphone, qu’il tombe en panne, ou que tu réinstalles ton app d’authentification sans sauvegarde ? Réponse brutale : sans filet, tu es définitivement enfermé dehors. Ton mot de passe ne suffit plus, et le code TOTP, perdu à jamais.

C’est là qu’interviennent les clés de récupération (recovery keys). Ce sont des codes à usage unique que tu génères à l’avance et que tu mets de côté en lieu sûr. Si tu perds ton second facteur, tu utilises une de ces clés à la place du code TOTP pour te reconnecter — une seule fois par clé. C’est ta sortie de secours.

⚠️ Ne saute pas cette étape. C’est précisément l’étape que les gens zappent « parce que ça marche déjà », et c’est exactement celle qui leur coûte une réinstallation complète le jour où le téléphone lâche.

Générer les clés

Toujours connecté en ton-prenom@pve, va dans Datacenter → Permissions → Two Factor, clique sur Add, puis cette fois choisis Recovery Keys.

Proxmox te demande ton mot de passe pour confirmer (fenêtre Add: TFA recovery keys).

Il génère ensuite 10 clés numérotées de 0 à 9. Un bandeau te prévient sans ambiguïté : « Please record recovery keys — they will only be displayed now ». Traduction : c’est maintenant ou jamais, elles ne seront plus jamais réaffichées. Deux boutons t’aident à les sauvegarder : Copy Recovery Keys (pour les coller dans ton gestionnaire de mots de passe) et Print Recovery Keys (pour une copie papier).

Les mettre en sécurité — tout de suite

C’est maintenant ou jamais : ces clés ne seront plus jamais réaffichées. Copie-les et range-les dans un endroit sûr et séparé de ton téléphone (sinon le filet et le trapèze tombent ensemble). Quelques bonnes options :

• Ton gestionnaire de mots de passe (par exemple Proton ou Vaultwarden, si tu l’auto-héberges déjà — cohérent avec la démarche).

• Imprimées sur papier, rangées physiquement.

• Un fichier chiffré sur un support que tu contrôles.

Ce qu’il ne faut pas faire : les laisser dans une note non chiffrée, dans un mail, ou dans le même téléphone que ton app TOTP.

💡 Comme pour le secret TOTP, je peux afficher ces clés dans l’article parce qu’elles appartiennent à une VM de démonstration détruite juste après. Sur ton vrai serveur, traite-les comme un trousseau de secours : aussi sensibles que ton mot de passe maître.

Chaque clé ne fonctionne qu’une fois. Quand tu en utilises une, elle est consommée. Tu peux à tout moment regénérer un nouveau lot (ce qui invalide l’ancien) depuis ce même écran.

4. Activer le pare-feu intégré de Proxmox

Proxmox embarque son propre pare-feu, sans rien à installer. Jusqu’ici, ton interface est protégée par un compte dédié et la 2FA — mais elle reste joignable par n’importe quelle machine capable de l’atteindre sur le réseau. Le pare-feu, c’est la dernière serrure : il décide qui a le droit ne serait-ce que de frapper à la porte.

Comprendre les trois niveaux

Le pare-feu Proxmox fonctionne sur trois niveaux, et c’est la source de confusion numéro un quand on débute :

• Datacenter : l’interrupteur global et les politiques par défaut. Tant que l’interrupteur est éteint ici, aucun pare-feu ne filtre quoi que ce soit, peu importe les autres niveaux.

• Node (ton serveur, ici LABHMT) : protège le serveur Proxmox lui-même — donc ton interface web et ton accès SSH. C’est là qu’on pose les règles d’accès au serveur.

• VM / conteneur : protège chaque machine virtuelle individuellement.

« Pourquoi ne pas tout faire au niveau Datacenter ? » C’est la question logique, et elle cache le piège principal. Le niveau Datacenter n’est pas l’endroit où l’on filtre l’accès à ton serveur : c’est l’interrupteur général plus les règles communes à tous les nœuds d’un cluster. Si tu actives le pare-feu au niveau Datacenter mais pas au niveau Node, le pare-feu ne filtre aucun trafic vers ton serveur — les règles ne s’appliquent à aucun des deux niveaux. Autrement dit, le Datacenter seul est un interrupteur qui ne commande rien tant que le Node n’est pas allumé lui aussi. C’est précisément ça qui donne aux gens la fausse impression d’être protégés alors qu’ils ne le sont pas.

Il y a aussi un argument de cohérence : une règle « autorise 8006 depuis mon LAN » posée au Datacenter s’appliquerait à tous tes futurs serveurs. Sur ton homelab à un seul nœud, ça ne change rien aujourd’hui ; mais le jour où tu ajoutes un deuxième serveur avec un réseau différent, cette règle « globale » te suit partout et peut ne plus coller. On pose donc les règles d’accès là où elles concernent réellement ce serveur : au niveau Node.

La logique qu’on applique, en résumé :

• Node : pare-feu activé + règles d’accès au serveur (8006, 22). C’est là que ça protège vraiment.

• Datacenter : politiques par défaut (Input/Output) + interrupteur global activé, sans quoi le Node ne filtre rien.

Aujourd’hui on se concentre sur la protection du serveur (niveaux Node + Datacenter). Le pare-feu par VM est un sujet à part qu’on verra plus tard.

L’ordre qui t’évite de te verrouiller dehors

Voici la règle d’or, et elle n’est pas négociable :

⚠️ On crée TOUJOURS la règle qui autorise ton accès AVANT d’activer le pare-feu. Si tu actives d’abord et règles ensuite, tu prends le risque de te couper l’accès à ta propre interface et de devoir aller dépanner depuis la console physique du serveur. L’ordre correct : 1) créer la règle d’autorisation, 2) régler les politiques, 3) seulement ensuite, activer.

Proxmox a bien une règle de protection qui laisse en général passer l’accès depuis ton réseau local, mais on ne va pas s’y fier aveuglément : selon ta configuration réseau (réseau séparé, accès à distance, VLAN), elle peut ne pas s’appliquer comme tu l’imagines. La méthode « règle d’abord » est sûre dans tous les cas. C’est un réflexe à prendre une fois pour toutes.

Étape 1 — Créer la règle d’autorisation

On autorise les deux portes dont tu as besoin pour administrer le serveur :

• 8006 : l’interface web de Proxmox.

• 22 : l’accès SSH au serveur.

Va sur ton node (LABHMT dans l’arborescence à gauche) → Firewall → Add.

Crée une première règle :

• Direction : in (trafic entrant).

• Action : ACCEPT.

• Interface : laisse vide. Une règle sans interface s’applique à toutes les interfaces du serveur — c’est plus simple et plus sûr quand on débute, car on n’a pas à se soucier de savoir quel bridge porte l’administration.

• Protocol : tcp.

• Source : l’adresse ou la plage de ton réseau d’administration, en notation CIDR (par exemple 192.168.1.0/24 pour tout ton LAN). Restreindre à ton réseau plutôt que de laisser ouvert à tout le monde, c’est précisément l’intérêt.

• Dest. port : 8006. Attention : c’est bien le port de destination qu’on renseigne (la porte du serveur qu’on veut autoriser), pas le « Source port » qui, lui, doit rester vide — le port d’origine côté client est aléatoire.

• Comment : un libellé clair, par exemple Accès interface web depuis LAN.

⚠️ Mets TA vraie plage réseau, pas l’exemple. 192.168.1.0/24 n’est qu’un exemple. Si ton réseau est en 192.168.0.x, 10.0.0.x ou autre, mets ta plage à toi. Pour la connaître, regarde l’adresse IP de la machine depuis laquelle tu administres Proxmox. Te tromper ici, c’est te verrouiller dehors dès que tu actives le pare-feu — et devoir passer par le filet de secours de l’étape 4.

Recommence pour le port 22 (SSH), à l’identique en changeant juste le port de destination et le commentaire. Tu dois te retrouver avec deux règles, le port bien visible dans la colonne D.Port.

💡 Documente tes règles avec un commentaire. Dans six mois, tu ne te souviendras pas de pourquoi telle règle existe. Un commentaire par règle, c’est cinq secondes maintenant et une soirée gagnée plus tard.

Étape 2 — Régler la politique par défaut

Va dans Datacenter → Firewall → Options. C’est ici, au niveau Datacenter, que se règlent les politiques par défaut — ce que fait le pare-feu pour tout ce que tes règles n’ont pas explicitement traité :

• Input Policy : DROP — tout ce qui entre et n’est pas autorisé par une règle est jeté. C’est le cœur d’un pare-feu sain : on bloque par défaut, on autorise au cas par cas.

• Output Policy : ACCEPT — on laisse sortir librement le trafic du serveur. On pourra durcir ça plus tard, mais pour commencer, garder la sortie ouverte évite de casser des choses (mises à jour, DNS, etc.).

Étape 3 — Activer le pare-feu

⚠️ Avant d’activer, vérifie que tes règles sont vraiment là. Le blocage le plus courant vient de règles qui semblent créées dans l’interface mais ne sont pas réellement enregistrées au niveau du node. Avant d’allumer, contrôle trois choses : (1) tes règles 8006/22 apparaissent bien dans LABHMT → Firewall ; (2) leur Source correspond à TA vraie plage réseau ; (3) tu n’as pas oublié l’un des deux interrupteurs ci-dessous. Si une règle manque, tu te verrouilleras dès le passage en DROP.

Maintenant que la règle d’autorisation existe et que les politiques sont posées, on peut allumer. Deux interrupteurs à activer :

1. Au niveau Node : LABHMT → Firewall → Options → passe Firewall sur Yes. C’est ce qui fait réellement appliquer le filtrage sur ton serveur.

2. Au niveau Datacenter : Datacenter → Firewall → Options → passe Firewall sur Yes. C’est l’interrupteur global.

⚠️ Le piège qui rend tout le reste inutile. L’interrupteur Firewall du niveau Datacenter est sur No par défaut. Tant qu’il reste sur No, le pare-feu ne filtre rien — même si tes règles existent et que ta politique est sur DROP. Beaucoup de gens règlent tout consciencieusement, oublient ce dernier interrupteur, et croient être protégés alors que rien n’est actif. Vérifie qu’il est bien passé sur Yes.

Une fois les deux activés, le pare-feu filtre : seules tes machines autorisées peuvent atteindre l’interface et le SSH, tout le reste est bloqué.

Étape 4 — Le filet de secours (si jamais tu te verrouilles)

Même en suivant l’ordre, gardons une porte de sortie documentée. Si un jour tu te retrouves bloqué hors de ton interface à cause d’une règle, tout n’est pas perdu : tu peux toujours accéder à la console physique de ton serveur (écran + clavier, ou la console KVM de ton hébergeur). De là, deux options en ligne de commande :

pve-firewall stop

Cette commande arrête le pare-feu immédiatement, le temps que tu corriges ta règle depuis l’interface.

Ou, pour désactiver le pare-feu au niveau Datacenter en éditant directement le fichier de configuration :

nano /etc/pve/firewall/cluster.fw

Dans la section [OPTIONS], passe la ligne enable: 1 à enable: 0, sauvegarde, et le pare-feu global est coupé.

C’est la seule étape de tout cet article qui passe par la ligne de commande — et encore, uniquement en cas de pépin. Si tu as bien créé ta règle d’autorisation avant d’activer, tu ne devrais jamais en avoir besoin. Mais le connaître, c’est dormir tranquille.

5. Vérifier que tout fonctionne

C’est l’étape qui sépare « j’ai cliqué des trucs » de « mon serveur est verrouillé et je le sais ». On contrôle, dans l’ordre, que chaque serrure tient :

1. Le compte dédié + 2FA. Déconnecte-toi, puis reconnecte-toi avec ton compte ton-prenom@pve. Après le mot de passe, Proxmox doit te réclamer le code à 6 chiffres de ton app (écran Second login factor required). Si tu accèdes à tout l’environnement après avoir saisi le code, cette serrure tient.

2. Les clés de récupération. Tu n’as pas besoin d’en consommer une pour vérifier — ce serait du gâchis. Assure-toi simplement qu’elles sont rangées en lieu sûr, séparées de ton téléphone, et que tu sais où les retrouver le jour où tu en auras besoin.

3. Le pare-feu. Recharge l’interface : elle répond, donc ta règle d’autorisation pour le port 8006 fonctionne. Si tu as un second appareil sur ton réseau (un autre ordinateur, ton téléphone en Wi-Fi), connecte-toi à l’interface depuis lui aussi : ça confirme que tout ton LAN autorisé passe bien. Si tu veux pousser la vérification, tente une connexion depuis un appareil hors de ta plage autorisée (par exemple ton téléphone en 4G, hors Wi-Fi) : l’interface ne doit pas répondre. C’est la preuve que le pare-feu bloque réellement le reste.

Si ces trois points sont au vert, c’est gagné : ton interface Proxmox n’est plus accessible qu’avec ton compte, ton téléphone, et depuis ton réseau.

6. Ce qu’on a fait, et ce qui vient ensuite

Récapitulons le chemin parcouru. Ton interface Proxmox est passée d’un accès root unique et nu à quatre couches qui se complètent :

• Un compte dédié pour le quotidien — ta clé perso, au lieu du passe-partout.

• La double authentification sur ce compte et sur root — une seconde serrure qui résiste même à un mot de passe volé.

• Des clés de récupération mises de côté — ta sortie de secours si tu perds ton téléphone.

• Le pare-feu intégré, activé aux bons niveaux, qui ne laisse atteindre l’interface que depuis ton réseau.

C’est déjà un niveau de sécurité que beaucoup d’installations « en production » n’ont pas. Tu peux être satisfait du résultat.

Mais on n’a pas tout fait, et c’est volontaire. Une porte reste ouverte, qu’on a laissée de côté pour ne pas tout mélanger : l’accès SSH au système Debian qui héberge Proxmox. Pour l’instant, ce serveur se connecte encore probablement en root avec un mot de passe — exactement ce qu’on vient de corriger pour l’interface web, mais à l’étage en dessous. Désactiver le login root en SSH, passer aux clés plutôt qu’aux mots de passe, ajouter une protection contre les tentatives répétées : c’est le sujet de la deuxième partie. Et comme ce durcissement SSH vaut pour n’importe quel serveur Linux — pas seulement Proxmox — il te resservira partout, y compris sur ton VPS.