VxRail : ESXi SSH reste activé sur le nœud VxRail principal après un rapport consultatif nocturne sur la version 7.0.45x
Summary: ESXi SSH reste activé sur le nœud VxRail principal après le rapport d’avis nocturne sur la version 7.0.45x.
Symptoms
Cet article de la base de connaissances s’adresse aux clients qui ont des préoccupations en matière de sécurité si le service SSH est à l’état activé sur ESXi. Il est possible que la vérification nocturne du rapport d’avertissements VxRail laisse SSH dans un état activé sur le nœud VxRail principal.
Cela se produit lorsque les sous-modules de contrôle d’intégrité activent temporairement TSM-SSH sur les nœuds ESXi simultanément.
Scénario 1 :
Le sous-composant de bilan de santé « Radar » (qui fait partie des bilans de santé, vérifications préalables et ADC de VxRail) dispose de plusieurs modules qui font partie de son automatisation.
Les modules en question sont « vsan_disk_utilization_check » et « VxVerify » et sont en conflit l’un avec l’autre.
Exemple d’extrait de journal sur l’activation de SSH pour le module « vsan_disk_utilization_check » :
Radar.log from VxRail Manager: 2023-06-22 00:20:52,403.403Z INFO [vsan_disk_utilization_check] Running cmd on: hst011.cwf.fr > esxcli vsan health cluster get --test=diskspace|grep % [remote_utils.py:114] shell.log from primary VxRail node: 2023-06-21T00:20:53.214Z SSH[6061650]: SSH login enabled
Exemple d’extrait de journal relatif à la détection de l’état SSH sur tous les nœuds pour que VxVerify rétablisse son état SSH une fois l’opération terminée :
VxVerify vxv.log from the VxRail Manager: 2023-06-22 00:20:59-INFO [host_ssh_check] SSH status for node01.domain.tld is initially enabled
Exemple d’extrait de journal lors de la désactivation de SSH pour le module « vsan_disk_utilization_check »
Radar.log from VxRail Manager: 2023-06-22 00:21:35,582.582Z INFO [vsan_disk_utilization_check] Host hst011.cwf.fr ran cmd. Response: b'59.53% (145196.93GB of 243916.11GB) green 170741.28 219524.50 \n',b'Could not create directory \'/home/tcserver/.ssh\'.\r\nload pubkey "/home/tcserver/.ssh/id_ shell.log from primary VxRail node: 2023-06-21T00:21:36.870Z SSH[6061853]: SSH login disabled
Scénario 2 :
Run Quick boot script failed
2025-01-29T10:02:32.563Z <586bc3767ee3ca82a80f6e3ecac4b0b6> lcm [INFO] <189> NodeSSHManagementService.java enableSSHServiceWithOriginalStatusReturn() (152): SSH state: true
2025-01-29T10:02:32.563Z <586bc3767ee3ca82a80f6e3ecac4b0b6> lcm [ERROR] <189> QuickBootCompatibilityService.java runQuickbootScript() (70): get script Error
Cause
Lors de l’activation de SSH, exécutez la commande, puis désactivez SSH pour « vsan_disk_utilization_check », il aurait déjà détecté dans VxVerify (avant de désactiver SSH à partir de vsan_disk_utilization_check) que SSH est activé sur le nœud VxRail principal.
À la fin de VxVerify, il tente de restaurer ou de laisser SSH dans un état activé. Tel était l’état du service SSH au début de VxVerify.
Resolution
Scénario 1 :
Il existe deux façons de résoudre ce problème : L’une consiste à modifier la configuration pour désactiver le « vsan_disk_utilization_check » et l’autre consiste à mettre à niveau l’ADC vers la version fixe.
Résolution 1 :
Commandes permettant de désactiver et de valider l’état « vsan_disk_utilization_check » désactivé :
su to root
vxrm0:/mystic/radar # cd /mystic/radar
vxrm0:/mystic/radar # grep -i vsan_disk_utilization_check /mystic/radar/conf/profile/advisory-report.yml
- vsan_disk_utilization_check
vxrm0:/mystic/radar # cp /mystic/radar/conf/profile/advisory-report.yml /home/mystic/advisory-report.bckup
vxrm0:/mystic/radar # sed -i 's/^\( *\)- vsan_disk_utilization_check/# - vsan_disk_utilization_check/' /mystic/radar/conf/profile/advisory-report.yml
vxrm0:/mystic/radar # grep -i vsan_disk_utilization_check /mystic/radar/conf/profile/advisory-report.yml
# - vsan_disk_utilization_check
Désactivez et validez l’état désactivé pour ESXi TSM-SSH sur tous les nœuds.
Attendez que le « rapport consultatif » VxRail s’exécute pendant la nuit et vérifiez si SSH est laissé à l’état SSH désactivé.
Vous devrez peut-être réappliquer cette résolution, car /mystic/radar/conf/profile/advisory-report.yml sera rétabli lors de la mise à jour d’ADC.
Résolution 2 :
Reportez-vous à l’article KB# https://www.dell.com/support/kbdoc/000019890 pour mettre à niveau l’ADC vers la dernière version afin de résoudre ce problème.
Scénario 2 :
Mettez à niveau VxRail vers la version 8.0.330 ou une version supérieure.