Dans les environnements virtualisés sous VMware ESX 4.1, la politique de sécurité de la Service Console (l’environnement Linux d’administration basé sur Red Hat) est particulièrement stricte. Même lorsque le démon SSH est actif et qu’un compte d’administration secondaire est configuré avec un mot de passe valide, toute tentative de connexion à distance en dehors du compte root est automatiquement rejetée par défaut. Ce comportement découle d’un contrôle d’accès renforcé au niveau de la couche PAM (Pluggable Authentication Modules).
Comprendre le verrouillage par pam_access
Par défaut, la pile d’authentification SSH délègue le filtrage des connexions locales et distantes au module pam_access.so. Ce module s’appuie sur le fichier de règles /etc/security/access.conf. Dans une installation standard d’ESX 4.1, ce fichier contient une liste blanche très fermée, suivie d’un rejet explicite pour tous les autres profils :
+:root:ALL
+:vpxuser:ALL
+:vslauser:ALL
-:ALL:ALL
La dernière directive (-:ALL:ALL) interdit toute ouverture de session aux utilisateurs qui ne figurent pas explicitement au-dessus. Ainsi, ajouter simplement un utilisateur au système ne suffit pas : il faut adapter ce fichier sous peine de voir vos sessions refusées avec un message d’erreur d’autorisation générique dans les journaux.
Étape 1 : Créer le compte avec un shell valide
Avant d’ajuster les contrôles de sécurité, l’utilisateur doit exister dans l’environnement système avec un interpréteur de commandes valide. Connectez-vous à la console en root et lancez :
useradd -m -s /bin/bash admintech
passwd admintech
Veillez à lui attribuer un shell conventionnel comme /bin/bash. Si vous organisez vos scripts ou vos binaires d’administration à l’aide d’un lien symbolique linux, assurez-vous également que les chemins cibles restent lisibles par ce nouvel utilisateur.
Étape 2 : Modifier /etc/security/access.conf
Ouvrez le fichier de configuration avec votre éditeur habituel (par exemple vi ou nano) :
vi /etc/security/access.conf
Repérez la ligne de refus global située en fin de fichier. Vous devez impérativement déclarer votre utilisateur avant la directive -:ALL:ALL, car les règles sont interprétées dans l’ordre séquentiel du haut vers le bas. Ajoutez la permission correspondante :
+:admintech:ALL
Le bloc final doit ressembler à ceci :
+:root:ALL
+:vpxuser:ALL
+:vslauser:ALL
+:admintech:ALL
-:ALL:ALL
Cette syntaxe indique que le compte admintech est autorisé à se connecter depuis n’importe quelle source réseau ou terminal (ALL). Vous pouvez restreindre cette directive à un sous-réseau spécifique pour renforcer la sécurité (par exemple +:admintech:192.168.1.0/24).
Étape 3 : Relancer le service SSH
Pour que les modifications de configuration soient appliquées proprement au service d’écoute à distance, redémarrez le démon SSH :
service sshd restart
ou
/etc/init.d/sshd restart
Testez immédiatement une connexion distante depuis votre poste de travail. Une fois authentifié, l’utilisateur a accès au terminal restreint sans posséder directement les privilèges d’administration totale du serveur. Si vous devez intervenir sur un hyperviseur saturé ou clore une session orpheline laissée ouverte par un technicien, pensez à déconnecter une session en ligne de commande avant de poursuivre vos maintenances.
Bonnes pratiques et évolution vers ESXi
Bien que cette procédure soit propre à l’architecture ESX « Classic » avec console de service, rappelons que les versions ultérieures (ESXi 5.x et plus récentes) ont totalement abandonné cette architecture Linux au profit d’un environnement allégé sans console Red Hat. Sur ces systèmes modernes, l’accès SSH se gère directement via les rôles vCenter, le shell ESXi intégré (BusyBox) et le client Host Client Web.
Si vous maintenez encore des hôtes ESX 4.1 isolés pour des raisons applicatives patrimoniales, appliquez toujours le principe du moindre privilège : ne partagez jamais le mot de passe root et privilégiez ces comptes nominatifs restreints pour la traçabilité des interventions.
