Durcir un hôte PVE et PBS : SSH, accès GUI, certificats ACME¶

Day 1 · DéployerNiveau 2 · OpérerChecklistRédigé · à valider en lab

Cette checklist ramène un hôte Proxmox VE (pve01) ou Proxmox Backup Server à un niveau de sécurité raisonnable : interface d'administration non exposée, SSH par clés, certificats valides, comptes nominatifs et mises à jour suivies. Chaque point se vérifie par une commande ou un écran.

Avant de toucher la prod

Accès console hors bande (IPMI/iDRAC/iLO) testé : une erreur SSH ou firewall se rattrape en console.
Une session root ouverte en parallèle pendant toute modification de sshd ou pveproxy.
Clé SSH de l'équipe et clé du MSP déjà déposées et testées.
Sur un cluster : appliquer nœud par nœud, vérifier pvecm status entre deux nœuds.

1. Exposition réseau¶

La GUI PVE (port 8006) et PBS (port 8007) ne sont joignables que depuis le réseau d'administration, jamais depuis Internet. Test depuis un poste extérieur : curl -k -m 5 https://<ip-publique>:8006 doit échouer.
Interfaces de management sur un VLAN dédié, distinct des réseaux de VM, voir plan réseau type.
Firewall PVE actif avec un IPset management à jour : Datacenter → Firewall → Options = Yes. Voir Firewall Proxmox.
PBS filtré par nftables local ou par le firewall réseau : seuls les nœuds PVE, les postes admin et le PBS du MSP atteignent le port 8007.
Si un filtrage applicatif complémentaire est souhaité sur PVE, /etc/default/pveproxy (puis systemctl restart pveproxy.service spiceproxy.service) :
```
ALLOW_FROM="10.10.0.0/24,10.99.0.0/24"
DENY_FROM="all"
POLICY="allow"
```
Vérification : grep -E 'ALLOW|DENY|POLICY' /etc/default/pveproxy. Ne pas utiliser LISTEN_IP sur un nœud de cluster.

2. SSH¶

Fichier de durcissement dédié, sans modifier sshd_config d'origine, /etc/ssh/sshd_config.d/90-durcissement.conf :

PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
MaxAuthTries 3
X11Forwarding no

Syntaxe validée avant rechargement : sshd -t && systemctl reload ssh.
Configuration effective : sshd -T | grep -E 'permitrootlogin|passwordauthentication' affiche prohibit-password et no.
Test de connexion par clé depuis un nouveau terminal avant de fermer l'ancien.
Sur un cluster PVE, PermitRootLogin n'est pas à no : les nœuds communiquent en root par clé (migration, réplication ZFS, console). Test : ssh -o BatchMode=yes root@pve02 hostname depuis pve01 répond sans mot de passe.
Clés autorisées revues : cat /root/.ssh/authorized_keys. Sur PVE, les clés des nœuds sont gérées par le cluster via /etc/pve/priv/authorized_keys : ne pas supprimer ces lignes ni écraser le fichier.
fail2ban installé si le SSH est joignable depuis un réseau non maîtrisé (apt install fail2ban, puis fail2ban-client status sshd).

3. Certificats¶

Accès à la GUI par FQDN (https://pve01.corp.local:8006), pas par IP. Prérequis pour WebAuthn.
Certificat valide reconnu par les navigateurs, au choix :
- ACME (Let's Encrypt ou CA ACME interne). PVE : Datacenter → ACME (compte + plugin DNS), puis Nœud → System → Certificates → ACME → Add le domaine, Order Certificates Now. PBS : Configuration → Certificates.
- Certificat de la PKI interne : Nœud → System → Certificates → Upload Custom Certificate.

Commandes PVE équivalentes, à tester d'abord avec l'annuaire staging de Let's Encrypt :

pvenode acme account register default admin@corp.local
pvenode acme plugin add dns ovh-dns --api ovh --data /root/ovh.ini
pvenode config set --acmedomain0 pve01.corp.local,plugin=ovh-dns
pvenode acme cert order

Renouvellement automatique actif : géré par pve-daily-update.service, tenté à 30 jours de l'échéance. Vérification : pvenode cert info | grep -i notafter.
Certificat du serveur PBS : empreinte relevée (Dashboard → Show Fingerprint) et identique à celle déclarée dans le stockage pbs-local (grep -A6 pbs-local /etc/pve/storage.cfg). Changer le certificat PBS change l'empreinte : mettre à jour le stockage côté PVE et la synchronisation côté MSP.

4. Comptes et accès¶

Mot de passe root long, unique par hôte, stocké au coffre.
Un compte nominatif par administrateur, via annuaire, avec 2FA : voir Authentification et 2FA.
2FA sur root@pam et clés de récupération imprimées au coffre.
Revue trimestrielle : pveum user list et pveum acl list (PVE), proxmox-backup-manager user list (PBS). Aucun compte de personne partie.
Jetons API inventoriés, avec date d'expiration : voir Jetons API.

5. Système et mises à jour¶

Dépôts au format deb822 cohérents avec l'abonnement : ls /etc/apt/sources.list.d/*.sources, aucun dépôt pvetest en production. Voir abonnements et dépôts.
Mises à jour appliquées selon le runbook mises à jour rolling : apt update && apt list --upgradable vide après passage.
Aucun paquet inutile installé sur l'hyperviseur (pas de serveur web, de base de données ou d'agent non validé).
Heure synchronisée : chronyc tracking affiche Leap status : Normal. Indispensable pour TOTP, certificats et Ceph.
Notifications natives configurées vers une adresse surveillée : voir notifications.

6. Sauvegardes et clés¶

Sauvegardes PBS chiffrées côté client et clé hors cluster : voir Chiffrement.
Le compte utilisé par PVE sur PBS n'a que le rôle de sauvegarde sur son datastore, pas Admin : PBS → Datastore → Permissions.
Le compte de synchronisation du MSP ne peut pas supprimer les sauvegardes locales, voir sync vers le MSP.

Pièges vus en support

PermitRootLogin no appliqué sur un nœud de cluster : migrations et réplications en échec, console noVNC d'un autre nœud inaccessible.
/root/.ssh/authorized_keys écrasé par un outil de gestion de configuration : les nœuds ne se joignent plus. Les outils (Ansible…) doivent ajouter des lignes, pas remplacer le fichier.
Certificat ACME commandé en production pour un FQDN mal résolu : quota Let's Encrypt atteint. Toujours tester en staging.
Port 8006 publié en NAT « temporairement » pour un prestataire : accès exposé des mois plus tard. Utiliser un VPN ou le bastion du MSP.

Quand ouvrir un ticket iTop

Accès SSH ou GUI perdu sur un nœud après durcissement : P2 (P1 si plusieurs nœuds). Mise en place d'une CA ACME interne, audit de sécurité, revue de conformité : demande P4. Contrat N3 : le MSP applique et maintient cette checklist.

Ouvrir un ticket iTop

Documentation officielle : Certificate Management · pveproxy(8) · PBS Certificate Management