Sur Proxmox VE, le service SSH est actif dès l’installation et le compte root peut s’y connecter par mot de passe : c’est pratique, mais ce n’est pas une configuration à conserver. Que votre serveur Proxmox VE tourne dans un homelab ou sur un hôte physique en entreprise, l’accès SSH à votre hyperviseur représente une surface d’attaque importante. Ceci est d’autant plus vrai lorsqu’il est question d’un accès root, car il offre un accès root complet à la machine et, par extension, à toutes les VM et conteneurs qu’elle héberge. Configurer et sécuriser l’accès SSH est l’une des premières étapes à effectuer suite à l’installation de Proxmox VE.
Dans ce tutoriel, nous allons voir comment configurer l’accès SSH sur Proxmox VE de manière propre et sécurisée : génération d’une paire de clés, déploiement de la clé publique sur le serveur, désactivation de l’authentification par mot de passe, puis mise en place d’un compte d’administration dédié. Même si Proxmox VE s’appuie sur Debian, il y a quelques subtilités qu’il est important de connaître. Les manipulations qui suivent ont été réalisées sur Proxmox VE 9.2, basé sur Debian 13.
Voici la méthode rapide pour les plus pressés d’entre vous. Pour activer l’authentification par clé SSH sur un serveur Proxmox VE, la procédure se résume à cinq étapes :
Générer une paire de clés SSH sur votre poste de travail avec ssh-keygen -t ed25519.
Copier la clé publique sur le serveur Proxmox VE avec ssh-copy-id root@, ce qui l’ajoute au fichier /etc/pve/priv/authorized_keys.
Vérifier que la connexion ssh root@ fonctionne sans mot de passe.
Créer un fichier de durcissement dans /etc/ssh/sshd_config.d/ avec PermitRootLogin prohibit-password et PasswordAuthentication no, puis recharger le service avec systemctl reload ssh.
Tester la nouvelle configuration depuis un second terminal avant de fermer la session en cours.
La suite de l’article détaille chaque étape, avec les spécificités de Proxmox VE à connaître.
SSH sur Proxmox VE : ce qu’il faut savoir avant de commencer
Proxmox VE est une distribution basée sur Debian, ce qui signifie que le serveur SSH est l’implémentation habituelle : OpenSSH Server. Si vous avez l’habitude de configurer un accès SSH sur un serveur Linux, alors vous ne serez pas perdu, mais il y a des différences à connaître.
SSH est actif par défaut, et root peut se connecter par mot de passe
Première différence importante : contrairement à une installation Debian, où la connexion root par mot de passe est refusée en SSH, Proxmox VE autorise la connexion SSH en tant que root (soit dans la configuration de SSH : PermitRootLogin yes). En pratique, dès que l’installation est terminée et que votre serveur Proxmox VE est connecté au réseau, vous pouvez ouvrir un terminal et vous connecter :
ssh [email protected]
Lors de la configuration initiale d’un nœud Proxmox VE, cela peut être intéressant, mais cela doit être temporaire. Conserver un accès root par mot de passe exposé sur le réseau, c’est aussi une cible idéale pour les attaquants. En tant qu’admin de votre serveur, vous devez reprendre la main sur cette configuration.
Comptes Linux et utilisateurs Proxmox VE : deux mondes distincts
Proxmox VE dispose de son propre système d’utilisateurs, avec plusieurs domaines d’authentification (les realms) : pam pour les comptes Linux du système, pve pour les comptes propres à Proxmox VE, mais aussi LDAP, Active Directory ou OpenID Connect. Toutefois, dans le contexte de SSH, il faut savoir que :
L’accès SSH repose uniquement sur les comptes Linux du système (le realm pam), c’est-à-dire ceux présents dans /etc/passwd.
Un utilisateur créé dans l’interface web dans le realm pve n’existe pas au niveau du système : il ne pourra jamais ouvrir de session SSH, même avec le rôle Administrator.
L’authentification à deux facteurs (TOTP, WebAuthn) configurée dans l’interface web protège uniquement l’interface web et l’API, pas l’accès SSH.
Autre point à connaître : l’interface web de Proxmox VE ne propose aucun menu pour gérer les clés SSH de l’hôte lui-même. Le champ Clé publique SSH que vous rencontrez dans l’assistant de création d’une machine virtuelle concerne cloud-init, donc la VM invitée, pas l’hyperviseur. La gestion des clés SSH de l’hôte se fait obligatoirement en ligne de commande.
Le cas des clusters : un fichier authorized_keys partagé
Sur un nœud Proxmox VE, le fichier /root/.ssh/authorized_keys n’est pas un fichier ordinaire, mais un lien symbolique vers /etc/pve/priv/authorized_keys. C’est vérifiable facilement avec cette commande :
ls -l /root/.ssh/authorized_keys
À quoi correspond ce répertoire vers lequel pointe le lien symbolique ? Le répertoire /etc/pve est le point de montage du système de fichiers de cluster de Proxmox VE (pmxcfs), répliqué en temps réel sur tous les nœuds via Corosync. Ce mécanisme existe parce que Proxmox VE utilise des tunnels SSH entre les nœuds pour plusieurs fonctions : la migration des VM et des conteneurs, la réplication du stockage, ou encore l’ouverture du shell d’un autre nœud depuis l’interface web. Chaque nœud possède donc sa propre paire de clés (/root/.ssh/id_rsa) et la clé publique de chaque nœud est ajoutée dans ce fichier partagé.
Dans le cas de la gestion de l’accès SSH tel qu’évoqué dans cet article, il y a plusieurs conséquences :
Une clé publique ajoutée dans /etc/pve/priv/authorized_keys donne un accès root à tous les nœuds du cluster, immédiatement.
Sur un nœud isolé, le lien symbolique est présent aussi, mais il n’a pas d’incidence particulière.
Il ne faut jamais remplacer ce lien par un fichier classique : vous casseriez les opérations inter-nœuds.
Prérequis
Pour suivre ce tutoriel, vous avez besoin :
D’un serveur Proxmox VE installé et joignable sur le réseau (ici, prox-01 avec l’adresse IP 192.168.110.3).
Du mot de passe root de ce serveur, puisque la première connexion se fera par mot de passe.
D’un poste de travail disposant d’un client OpenSSH : c’est le cas nativement sous Linux, macOS et Windows 10/11.
Falcultatif – Un accès de secours à la console du serveur : soit la console physique, soit l’accès distant (iDRAC, iLO, IPMI), soit tout simplement l’interface Web (elle donne accès au shell).
Si vous travaillez depuis Windows, le client SSH intégré à Windows est suffisant. Je vous renvoie vers ce tutoriel pour la prise en main : comment utiliser le client SSH natif de Windows.
Générer une paire de clés SSH sur votre poste
La paire de clés se génère sur votre poste de travail, jamais sur le serveur. D’ailleurs, la clé privée ne doit pas quitter la machine qui l’a créée : c’est une règle d’or. La commande est identique sous Linux, macOS et Windows :
ssh-keygen -t ed25519 -C “florian@pc”
Quelques précisions sur la syntaxe de cette commande :
-t ed25519 : l’algorithme Ed25519 est aujourd’hui le choix recommandé et adapté pour Proxmox VE.
-C : un simple commentaire, ajouté à la fin de la clé publique. Il n’a aucun rôle cryptographique, mais il facilite l’identification des clés lorsqu’il y en a plusieurs dans un fichier authorized_keys. Précisez qui et quel poste, afin d’en faire une information utile.
La passphrase : ssh-keygen vous propose de protéger la clé privée par une phrase secrète. Je vous recommande d’en définir une. Sans elle, toute personne qui récupère le fichier de clé privée peut l’utiliser directement. Pour éviter de la saisir à chaque connexion, vous pouvez utiliser un agent SSH, comme expliqué dans ce tutoriel : éviter de saisir sa passphrase à chaque utilisation d’une clé SSH.
Deux fichiers sont créés dans le dossier .ssh de votre profil (~/.ssh/ sous Linux et macOS, C:\Users\\.ssh\ sous Windows) :
id_ed25519 : la clé privée, à conserver précieusement et à ne jamais transmettre.
id_ed25519.pub : la clé publique, celle que nous allons copier sur le serveur Proxmox VE.
Déployer la clé publique sur le serveur Proxmox VE
Il existe plusieurs façons de copier la clé publique sur le serveur. Choisissez celle qui correspond à votre poste de travail.
Méthode 1 : avec ssh-copy-id (Linux et macOS)
La commande ssh-copy-id fait tout le travail : elle se connecte au serveur avec le mot de passe root, crée le dossier .ssh si nécessaire et ajoute la clé publique à la fin du fichier authorized_keys.
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
Le mot de passe root vous est demandé pour établir la connexion. Comme /root/.ssh/authorized_keys pointe vers /etc/pve/priv/authorized_keys, la clé est ajoutée directement dans le fichier partagé du cluster.
Méthode 2 : depuis Windows avec PowerShell
Le client OpenSSH de Windows ne fournit pas ssh-copy-id. L’équivalent consiste à envoyer le contenu de la clé publique au serveur, qui l’ajoute lui-même au fichier authorized_keys. Cela donne une commande différente, mais c’est le même résultat obtenu :
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh [email protected] “cat >> ~/.ssh/authorized_keys”
Là encore, le mot de passe root est demandé pour cette connexion. Si cette commande réussit, elle ne retourne rien.
Méthode 3 : manuellement, depuis le shell de l’interface web
Si vous préférez ne pas passer par une connexion SSH par mot de passe, même une seule fois, ouvrez le shell du nœud depuis l’interface web de Proxmox VE (Datacenter > prox-01 > Shell). Affichez le contenu de votre clé publique sur votre poste (cat C:\Users\Florian/.ssh/id_ed25519.pub), copiez-le, puis ajoutez-le au fichier partagé en saisissant la commande depuis le Shell web :
echo “ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP4mwCAbYLr1yfi+654nZSythohxelZPpczIGIYK3tG8 florian@pc” >> /etc/pve/priv/authorized_keys
Remplacez évidemment la chaîne par votre propre clé publique, sur une seule ligne.
Cas particulier : déclarer les clés dès l’installation automatisée
Si vous déployez vos serveurs Proxmox VE avec l’installation automatisée (fichier de réponses answer.toml), sachez que l’option root-ssh-keys de la section [global] permet de provisionner directement les clés publiques de root, sans aucune connexion par mot de passe après l’installation :
[global]
root-password-hashed = “$y$j9T$…”
root-ssh-keys = [
“ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP4mwCAbYLr1yfi+654nZSythohxelZPpczIGIYK3tG8 florian@pc”
]
Ce n’est pas vraiment le sujet si votre serveur est déjà installé, mais c’est toujours bon à savoir. Pour en savoir plus, ce point est documenté sur la page Automated Installation du wiki de Proxmox.
Tester la connexion par clé SSH
La configuration est prête, on teste ? Quelle que soit la méthode utilisée pour copier la clé publique, vous pouvez tester dès maintenant.
ssh [email protected]
Si le serveur ne demande plus le mot de passe root (mais éventuellement la passphrase de votre clé), l’authentification par clé fonctionne. En cas de doute, l’option -v affiche le déroulement de l’authentification grâce au mode verbeux. Sinon, consultez les journaux SSH, vous devriez voir la connexion par clé SSH.
journalctl -u ssh –since “10 minutes ago” | grep Accepted
Vérifiez aussi que le fichier partagé contient bien votre clé, cela confirmera ce que j’ai affirmé précédemment.
cat /etc/pve/priv/authorized_keys
Dans le contenu, vous devriez voir cette ligne :
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP4mwCAbYLr1yfi+654nZSythohxelZPpczIGIYK3tG8 florian@pc
Désactiver l’authentification par mot de passe
Maintenant que l’authentification par clé fonctionne, nous pouvons durcir un peu la configuration de l’accès SSH en désactivant l’accès par mot de passe. C’est l’étape qui apporte un vrai gain en matière de sécurité.
Le fichier sshd_config et le dossier sshd_config.d sous Debian 13
Sur Proxmox VE 9 (Debian 13), la configuration d’OpenSSH ne se limite pas au fichier /etc/ssh/sshd_config. Si l’on met de côté les commentaires, la première directive activée est une directive Include. En réalité, tous les fichiers .conf présents dans /etc/ssh/sshd_config.d/ sont chargés avant le reste du fichier principal. Et OpenSSH applique une règle simple : pour chaque option, la première valeur rencontrée l’emporte.
Créer le fichier de durcissement
Le dossier mentionné précédemment est vide par défaut. Nous allons créer notre propre fichier de configuration, en pensant à ajouter un numéro comme préfixe. Il sert simplement à maîtriser l’ordre de chargement si d’autres fichiers venaient à s’ajouter.
nano /etc/ssh/sshd_config.d/10-proxmox-hardening.conf
Contenu du fichier :
PermitRootLogin prohibit-password
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
Quelques explications s’imposent :
PermitRootLogin prohibit-password : root peut toujours se connecter, mais uniquement avec une clé. C’est la valeur à retenir sur Proxmox VE. La valeur no bloquerait toute connexion root en SSH, y compris par clé, ce qui casserait la migration des VM, la réplication et l’accès aux shells des autres nœuds dans un cluster. Sur un nœud isolé, no est techniquement possible, mais vous perdriez cette compatibilité le jour où vous mettez en place un cluster.
PubkeyAuthentication yes : c’est la valeur par défaut, mais au moins elle est spécifiée noir sur blanc.
PasswordAuthentication no : désactive l’authentification par mot de passe pour tous les utilisateurs.
KbdInteractiveAuthentication no : désactive l’authentification interactive au clavier, qui passe par PAM et peut, dans certaines configurations, redemander un mot de passe même lorsque PasswordAuthentication est à no.
PermitEmptyPasswords no : refuse les comptes sans mot de passe.
Valider et appliquer la configuration sans se déconnecter
Avant de recharger le service, validez la syntaxe :
sshd -t
Aucune sortie signifie que la configuration est valide. Pour appliquer la configuration, effectuez un reload sur le service SSH.
systemctl reload ssh
Ne fermez pas votre session actuelle. Ouvrez un second terminal et tentez une nouvelle connexion avec la clé. Si elle aboutit, testez également qu’une connexion sans clé est bien refusée :
ssh -o PubkeyAuthentication=no [email protected]
Aller plus loin : un compte d’administration dédié plutôt que root
Se connecter directement en root, même par clé, c’est plus que discutable. Il est préférable d’avoir un compte nominatif, en particulier s’il y a plusieurs administrateurs (c’est un plus pour la traçabilité). Sur un serveur Proxmox VE, il est tout à fait possible d’utiliser un autre compte Linux pour l’accès SSH, puis d’élever ses privilèges avec sudo. Pour autant, il n’est pas possible de couper totalement l’accès root via SSH, en particulier pour les clusters (sauf erreur de ma part).
Créer le compte et installer sudo
Le paquet sudo n’est pas installé par défaut sur Proxmox VE. Depuis une session root :
apt update && apt install sudo
Puis, créez un utilisateur à votre nom et ajoutez le au groupe sudo.
adduser adm_fb
usermod -aG sudo adm_fb
Ajoutez ensuite votre clé publique au fichier authorized_keys de ce compte. Contrairement à root, ce fichier est local au nœud : dans un cluster, il faudra le répéter sur chaque nœud où l’accès est souhaité. Le plus simple est d’utiliser ssh-copy-id depuis votre poste, qui crée le dossier .ssh, ajoute la clé et applique les bonnes permissions :
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
Cette commande s’authentifie avec le mot de passe défini lors du adduser. Elle ne fonctionne donc que si l’authentification par mot de passe est encore acceptée par le serveur. Si vous créez ce compte avant l’étape de durcissement, c’est le cas. Si vous l’avez déjà désactivée, passez par votre session root, qui dispose de la clé, pour déposer le fichier à la place du compte. Ca fait une commande relativement lourde, mais ça passe (la commande ne retournera rien en cas de succès).
cat ~/.ssh/id_ed25519.pub | ssh [email protected] “install -d -m 700 -o adm_fb -g adm_fb /home/adm_fb/.ssh && cat >> /home/adm_fb/.ssh/authorized_keys && chown adm_fb:adm_fb /home/adm_fb/.ssh/authorized_keys && chmod 600 /home/adm_fb/.ssh/authorized_keys”
Les permissions sont importantes : OpenSSH ignore silencieusement un fichier authorized_keys accessible en écriture au groupe ou aux autres. Testez ensuite depuis votre poste :
ssh [email protected]
sudo -i
Donner accès à l’interface web à ce même compte
Le compte Linux existe, mais Proxmox VE ne le connaît pas encore. Si vous souhaitez que ce nouvel utilisateur soit aussi en capacité de se connecter à l’interface web et à l’API, il faut le déclarer dans le realm pam et lui attribuer un rôle. L’exemple ci-dessous lui associe le rôle Administrator sur la racine (donc sur tout).
pveum user add adm_fb@pam –comment “Administrateur – Florian”
pveum acl modify / –users adm_fb@pam –roles Administrator
Exemple :
Le mot de passe utilisé pour se connecter à l’interface web est le mot de passe Linux du compte (celui défini avec adduser). Vous pouvez ensuite activer l’authentification à deux facteurs sur ce compte depuis l’interface web (Datacenter > Permissions > Two Factor), ce qui protégera l’accès web, l’accès SSH étant déjà protégé par la clé.
Bonnes pratiques complémentaires
L’authentification par clé, c’est la base de la sécurisation de l’accès. Pour ceux qui ont la volonté d’aller plus loin, voici quelques mesures qui la complètent utilement sur un hôte Proxmox VE.
Restreindre l’accès SSH avec le pare-feu de Proxmox VE
Proxmox VE embarque un pare-feu gérable depuis l’interface web, au niveau du datacenter, du nœud et de chaque VM. Une règle limitant le port 22 (et le port 8006 de l’interface web) au sous-réseau ou à l’adresse IP de votre poste d’administration réduit fortement la surface d’exposition. La mise en œuvre est détaillée dans ce tutoriel : protéger votre serveur Proxmox VE et les VM avec le pare-feu natif. Vous pourriez aussi décider de modifier le port par défaut de l’accès SSH.
Bloquer les tentatives répétées avec Fail2ban
Même sans mot de passe accepté, les tentatives de connexion continueront d’arriver si le serveur est exposé sur le Web. C’est une réalité s’il s’agit d’une installation de Proxmox VE sur un serveur dédié. Un outil comme Fail2ban permet de bannir temporairement les adresses IP trop insistantes, sur SSH comme sur l’interface web de Proxmox VE. Pour démarrer avec cet outil : premiers pas avec Fail2ban.
Ajouter un second facteur sur SSH, avec prudence
Il est possible d’ajouter un code TOTP à l’authentification SSH via le module PAM libpam-google-authenticator, comme expliqué dans cet article : activer le MFA sur un accès SSH sous Linux. Sur Proxmox VE, cette procédure demande trois adaptations, sans quoi vous risquez de faire de la casse (en particulier sur un cluster).
La première règle à appliquer : réservez le second facteur au compte nominatif, jamais à root. Les tunnels SSH ouverts automatiquement entre les nœuds d’un cluster sont non interactifs et ne pourront pas saisir de code TOTP… Dans la configuration, la restriction se fait avec un bloc Match User, que nous plaçons dans un fichier de configuration, donc ce sera suffisant pour appliquer le MFA SSH uniquement sur certains comptes.
Enrôlez d’abord le compte, en étant connecté avec celui-ci :
sudo apt install libpam-google-authenticator
google-authenticator
Configurez ensuite PAM pour le service SSH. Deux modifications dans /etc/pam.d/sshd :
# Désactiver la demande de mot de passe (inutile avec la clé), en commentant cette ligne
#@include common-auth
# Ajouter le second facteur TOTP à la fin du fichier
auth required pam_google_authenticator.so
Ce fichier ne concerne que le service SSH. L’authentification du realm pam dans l’interface web de Proxmox VE passe par un service PAM distinct (proxmox-ve-auth), qui n’est donc pas affecté. Enfin, complétez le fichier de durcissement créé précédemment pour exiger clé et code sur ce seul compte.
sudo nano /etc/ssh/sshd_config.d/10-proxmox-hardening.conf
Le bloc Match doit être ajouté en toute fin de fichier, après les directives globales, car tout ce qui le suit dans le même fichier tombe sous sa portée (et s’applique donc au compte mentionné) :
Match User adm_fb
KbdInteractiveAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
La directive KbdInteractiveAuthentication yes est nécessaire, car le code TOTP transite par ce mécanisme, que notre fichier de durcissement désactive globalement.Validez et rechargez, puis contrôlez que root n’est pas concerné :
# Vérifier la configuration effective pour root, puis pour adm_fb
sudo sshd -t && sudo systemctl reload ssh
sshd -T -C user=root,host=prox-01,addr=192.168.110.5 | grep -Ei “^(authenticationmethods|kbdinteractiveauthentication)”
sshd -T -C user=adm_fb,host=prox-01,addr=192.168.110.5 | grep -Ei “^(authenticationmethods|kbdinteractiveauthentication)”
À la connexion suivante avec adm_fb, la clé est vérifiée, puis un Verification code: est demandé. Comme toujours, testez depuis un second terminal avant de fermer la session en cours. Comme le montre l’image ci-dessous, cela fonctionne.
Simplifier les connexions avec un fichier de configuration client
Sur votre poste, le fichier ~/.ssh/config évite de retaper l’adresse IP, l’utilisateur et le chemin de la clé à chaque fois :
# Serveur Proxmox VE du lab
Host prox-01
HostName 192.168.10.20
User adm_fb
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
La commande ssh prox-01 suffit alors à initier une connexion. Encore mieux : utilisez un gestionnaire de connexions, c’est utile si vous avez plusieurs serveurs.
Bonus – Accéder à l’interface web à travers un tunnel SSH
Puisque l’accès SSH est désormais en place, il peut servir de porte d’entrée unique. Je m’explique. Vous pouvez désactiver l’accès en direct à l’interface web de votre serveur Proxmox VE. Dans ce cas, vous réservez l’accès au port 8006 via un tunnel SSH :
ssh -L 8006:127.0.0.1:8006 [email protected]
Il suffit ensuite d’ouvrir https://localhost:8006 dans votre navigateur. Le tunnel fonctionne aussi pour les consoles noVNC et le shell, puisqu’ils passent par le même port.
Mais attention, le tunnel seul n’interdit rien : tant que pveproxy écoute sur toutes les interfaces, l’accès direct reste possible. Pour le fermer, le fichier /etc/default/pveproxy propose deux mécanismes. Sur un nœud isolé, par exemple un serveur hébergé chez un prestataire où seul le port 22 est ouvert, le plus radical consiste à ne faire écouter pveproxy que sur la boucle locale :
echo ‘LISTEN_IP=127.0.0.1’ >> /etc/default/pveproxy
systemctl restart pveproxy.service spiceproxy.service
Pour revenir en arrière, supprimez la ligne et redémarrez les mêmes services. L’accès SSH n’étant pas concerné par ce réglage, vous gardez toujours la main :
sed -i ‘/^LISTEN_IP=/d’ /etc/default/pveproxy
systemctl restart pveproxy.service spiceproxy.service
Attention : la documentation déconseille LISTEN_IP sur un cluster, car les nœuds communiquent entre eux via pveproxy sur le port 8006. Notez aussi qu’un redémarrage de pveproxy (à la différence d’un rechargement) interrompt les consoles et shells ouverts.
Sur un cluster, ou si vous souhaitez garder un accès direct depuis quelques adresses, utilisez plutôt l’ACL intégrée à pveproxy. La source 127.0.0.1 correspond au trafic qui arrive par le tunnel, et les adresses des autres nœuds doivent figurer dans la liste :
# /etc/default/pveproxy : accès autorisé via le tunnel SSH, depuis le poste d’administration et les autres nœuds
ALLOW_FROM=”127.0.0.1,192.168.110.5,192.168.110.4″
DENY_FROM=”all”
POLICY=”allow”
Vérifiez le résultat depuis votre poste : https://192.168.110.3:8006 doit échouer, tandis que https://localhost:8006 via le tunnel doit fonctionner. Ces réglages sont détaillés dans la documentation de pveproxy.
Et le pare-feu Proxmox VE dans tout ça ?
Le pare-feu Proxmox VE se comporte différemment selon le contexte. Ses règles par défaut acceptent les ports 8006 et 22 depuis l’IP set management, qui inclut automatiquement le réseau local détecté, et ces règles sont évaluées avant les vôtres. Dans un homelab, cela signifie que tout le LAN garde l’accès au 8006, d’où l’intérêt des réglages de pveproxy ci-dessus. Sur un serveur dédié avec une adresse IP publique, c’est l’inverse : le réseau détecté peut être le bloc entier du prestataire, et le pare-feu devient indispensable.
Dans ce cas, configurez le pare-feu pour bloquer les connexions entrantes et n’autoriser les ports 22 et 8006 que depuis vos adresses d’administration. Un seul piège à connaître : l’alias local_network, détecté automatiquement, doit être forcé à l’adresse du serveur dans /etc/pve/firewall/cluster.fw, sinon le bloc d’adresses du prestataire reste autorisé par les règles par défaut. La mise en œuvre est détaillée dans le tutoriel sur le pare-feu de Proxmox VE cité plus haut.
Dépannage : les erreurs les plus fréquentes
Permission denied (publickey) alors que la clé est en place
C’est le message le plus courant après la désactivation du mot de passe. Les causes habituelles :
Le client n’utilise pas la bonne clé. Vérifiez avec ssh -v la liste des clés proposées, ou forcez-la avec -i ~/.ssh/id_ed25519.
La clé publique a été collée sur plusieurs lignes ou avec un retour à la ligne parasite dans authorized_keys. Chaque clé doit tenir sur une seule ligne.
Pour un compte non-root, les permissions du dossier .ssh (700) ou du fichier authorized_keys (600) sont trop ouvertes, ou le propriétaire est incorrect.
Côté serveur, journalctl -u ssh indique généralement la raison exacte du refus.
Je suis enfermé dehors
Si plus aucune connexion SSH ne passe, l’interface web reste accessible : ouvrez le shell du nœud (Datacenter > prox-01 > Shell), puis ajustez la configuration du SSH. Vous pouvez simplement renommer le fichier /etc/ssh/sshd_config.d/10-proxmox-hardening.conf en ajoutant .bak, par exemple, et rechargez le service.
Si l’interface web est elle aussi inaccessible, il reste la console physique. C’est précisément pour cela que la vérification depuis un second terminal, avant de fermer la session, n’est pas optionnelle.
PermitRootLogin est repassé à yes
Si vous avez placé la directive directement dans /etc/ssh/sshd_config et que vous venez de créer ou de rejoindre un cluster, Proxmox VE l’a réécrite. Déplacez-la dans un fichier de /etc/ssh/sshd_config.d/ comme décrit plus haut, et contrôlez le résultat avec sshd -T.
Conclusion
Configurer l’accès SSH par clé sur Proxmox VE ne prend que quelques minutes, mais le gain est réel : plus aucune possibilité de faire du brute force sur l’accès SSH de votre serveur. Mais attention, rappelez-vous de la règle d’or : la clé privée qui ne quitte jamais votre poste.
Pour aller plus loin :
FAQ
SSH est-il activé par défaut sur Proxmox VE ?
Oui. Le serveur OpenSSH est installé et démarré dès l’installation de Proxmox VE, et l’installeur positionne la directive PermitRootLogin à yes dans /etc/ssh/sshd_config. Le compte root peut donc se connecter en SSH avec son mot de passe immédiatement après l’installation, sur le port 22.
Comment se connecter en SSH à un serveur Proxmox VE ?
Depuis un terminal Linux, macOS ou Windows, exécutez ssh root@ et saisissez le mot de passe root défini pendant l’installation. Une fois une clé SSH déployée, le mot de passe n’est plus demandé. Vous pouvez aussi ouvrir un shell directement depuis l’interface web, dans le menu du nœud.
Où ajouter une clé SSH pour root sur Proxmox VE ?
Dans le fichier /etc/pve/priv/authorized_keys. Le fichier /root/.ssh/authorized_keys n’est qu’un lien symbolique vers celui-ci. Il est répliqué sur tous les nœuds d’un cluster via pmxcfs, si bien qu’une clé ajoutée sur un nœud donne un accès root à l’ensemble du cluster. La commande ssh-copy-id fonctionne normalement et écrit au bon endroit. Toutefois, ce fichier est valable que pour les connexions SSH avec l’utilisateur root, car chaque utilisateur dispose de son fichier authorized_keys (comme précisé dans l’article).
Peut-on gérer les clés SSH de l’hôte Proxmox VE depuis l’interface web ?
Non. L’interface web ne propose pas de gestion des clés SSH de l’hyperviseur. Le champ de clé publique présent dans l’assistant de création d’une VM concerne cloud-init, c’est-à-dire la machine virtuelle invitée. Les clés de l’hôte se gèrent en ligne de commande, ou via le fichier de réponses lors d’une installation automatisée.
Faut-il mettre PermitRootLogin à no sur Proxmox VE ?
Non, il faut privilégier prohibit-password. Cette valeur autorise root uniquement par clé et bloque le mot de passe. La valeur no interdirait toute connexion root en SSH, y compris par clé, ce qui casserait la migration des VM, la réplication du stockage et l’accès aux shells des autres nœuds dans un cluster Proxmox VE.
Comment désactiver l’authentification par mot de passe SSH sur Proxmox VE ?
Après avoir vérifié que la connexion par clé fonctionne, créez un fichier dans /etc/ssh/sshd_config.d/ contenant PasswordAuthentication no, KbdInteractiveAuthentication no et PermitRootLogin prohibit-password. Validez avec sshd -t, rechargez avec systemctl reload ssh, puis testez depuis un second terminal avant de fermer votre session.
Comment copier une clé SSH sur Proxmox VE depuis Windows ?
Windows ne fournit pas ssh-copy-id. Depuis PowerShell, envoyez le contenu de la clé publique au serveur : type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh root@ “cat >> ~/.ssh/authorized_keys”. Le mot de passe root est demandé pour cette dernière connexion. Vous pouvez aussi coller la clé manuellement depuis le shell de l’interface web. Vous avez un exemple plus détaillé dans l’article.
Un utilisateur créé dans l’interface web de Proxmox VE peut-il se connecter en SSH ?
Seulement s’il s’agit d’un compte Linux du realm pam, créé au préalable sur le système avec adduser. Un utilisateur du realm pve n’existe qu’au niveau de Proxmox VE et ne peut pas ouvrir de session SSH, quel que soit son rôle. À l’inverse, un compte Linux doit être déclaré avec pveum user add pour accéder à l’interface web.
Le MFA de l’interface web Proxmox VE protège-t-il aussi SSH ?
Non. L’authentification à deux facteurs configurée dans Proxmox VE (TOTP, WebAuthn) s’applique à l’interface web et à l’API uniquement. L’accès SSH est géré par OpenSSH et PAM. Un second facteur sur SSH est possible via PAM, mais il doit être réservé aux comptes nominatifs, jamais à root, pour ne pas bloquer les tunnels SSH automatiques du cluster.
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.