VMESXi 4.0, accès root et authentification par clef SSH

closeCet article a été publié il y a 7 ans 11 mois 18 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

EDIT avril 2015 : pour ESXi 5, 5.1 et 6.0, cf. dans les commentaires.

Hello,

Ce qui suit était valable jusqu’à ESXi 4.0. Je n’ai pas regardé en 4.1 pour l’instant. Vous me direz (ou moi plus tard).
Cet article explique comment activer le serveur SSH sur un hôte VMWare ESXi 4.0 et comment mettre en place un « authorized_keys » durable (car le home du root saute à chaque reboot). Je présente aussi rapidement quelques trucs indispensables pour se promener dans l’hôte.
L’intérêt de la chose est de pouvoir lancer directement certaines commandes depuis un serveur ESXi via une session SSH et aussi, pour l’authentification par clef, de scripter certaines choses. Par exemple l’arrêt / copie des fichiers vmdk / relance de serveurs pour automatiser des full backup offline.

Let’s go!

Activation du SSH

Ce n’est pas supporté par VMWare, mais ça existe quand même. On se demande bien pourquoi 🙂
Sur la console de votre hôte, vous appuyez sur ALT-F1 pour passer sur une session console « habituelle » du monde Linux.
Là, en aveugle (pas d’écho à l’écran), vous tapez « unsupported », sans les guillemets bien sûr et validez par la touche « Entrée ».
Vous obtiendrez une demande de mot de passe, le pass de votre compte root.
Ca y est, vous êtes connecté à la console.
Vous pouvez alors aller éditer le fichier /etc/inetd.conf, avec l’éditeur « vi » et décommenter la ligne SSH en IPv4.
Ensuite, soit vous redémarrez le serveur, soit vous redémarrez inetd.
Testez votre connexion SSH depuis un autre ordi, histoire de valider.

Et maintenant ?

Super, je peux faire du SSH sur le serveur, mais pour quoi faire ?
Personnellement, il m’arrive de déplacer des machines virtuelles d’un serveur à l’autre, dont les fichiers vmdk ne sont pas sur un SAN partagé. Plutôt que de super-galérer avec le « vSphere Client » -> « Browse datastore » -> etc, je préfère faire faire quelques « scp » par exemple.
Et surtout, vous pouvez faire tout ce que permet « vSphere Client » mais en mode texte. Bref, parfois, c’est pratique.

vim-cmd

L’outil essentiel est la command « vim-cmd » (rien à voir avec « VIm »), documentez-vous dessus.
Commencez par taper « vim-cmd » tout seul, puis « vim-cmd vmsvc/ » par exemple. Les noms de fonctions sont souvent éloquents.

Vous pourrez par exemple :

  • obtenir la liste des VM : vim-cmd vmsvc/getallvms
  • obtenir l’état d’une VM : vim-cmd vmsvc/power.getstate <ID>
  • en arrêter proprement une (pas « électriquement ») : vim-cmd vmsvc/power.off <ID>
  • en rallumer une : vim-cmd vmsvc/power.on <ID>

etc…

Stockage des machines virtuelles

Dans /vmfs/volumes/, vous trouverez les noms de code de vos « datastores » et des liens symboliques pointant vers ces noms pourris, histoire de s’y retrouver. Ces liens sont les noms que vous avez affecté via « vSphere Client ».
De là, vous allez vite retrouver vos fichiers vmdk & co.

authorized_keys

Si vous avez besoin de stocker dans le home du root (qui est « / » et non un habituel « /root ») un fichier « ~/.ssh/authorized_keys », sachez qu’il saute à chaque reboot.
Ce que j’ai fait pour contrer celà, c’est d’ajouter au script « /etc/rc.local » la recopie de ce fichier stocké au préalable dans un « datastore » local.
Ca donne :

~ # tail /etc/rc.local
         if [ -f $filename ] && [ -x $filename ]; then
            log "running $filename"
            $filename
         fi
      done
fi

mkdir /.ssh
cd /vmfs/volumes/DataStoreLocal/pour_reboot/.ssh/
cp authorized_keys /.ssh/

J’avais d’abord créé ce fameux « pour_reboot » + le répertoire « .ssh/ » + le fichier « authorized_keys » dans le datastore qui va bien (ce n’est pas son nom d’origine, c’est plutôt « datastore1 » sur une machine fraîchement installée).

Et voilà, avec un accès SSH, un hôte ESXi ressemble quand même plus à quelque chose, non ? 🙂

6 réflexions au sujet de « VMESXi 4.0, accès root et authentification par clef SSH »

  1. feilong

    Merci pour l’astuce.
    Même si, l’ESXi nous sert juste à effectuer des tests (migrations, nouveaux logiciels, nouvelle version d’OS…) je vois pas ce que va m’apporter un accès ssh. Mais par principe, je vais essayer !

    Répondre
    1. michauko Auteur de l’article

      Baaaah, comme je disais : scripter des trucs.
      Après, pour une machine de tests, c’est pas forcément utile.

      Très belle attitude de geek au passage le « inutile, mais je vais essayer quand même ». J’aime beaucoup 🙂

      Répondre
  2. zebux

    En donnant l’astuce à un collègue, il m’a indiqué que l’on pouvait également passer par le fichier oem.tgz par avec les commandes suivantes :
    mkdir .ssh
    chmod 700 .ssh
    cp /root/.ssh/id_dsa.pub .ssh/authorized_keys
    chmod 600 .ssh/authorized_keys
    tar -czvf oem.tgz .ssh
    cp oem.tgz /bootbank/

    Je n’ai personnellement pas eu l’occasion de tester

    Répondre
    1. michauko Auteur de l’article

      OK, ça semble être la méthode propre en effet : un package prévu par un OEM (ou nous) pour descendre quelques outils au boot.
      Soit. Merci

      Répondre
  3. feilong

    Bon finalement la manipulation ne m’a pas servi que pour satisfaire mon côté geek.
    Elle m’a servi pour effectuer un upgrade ESX4.0 (j’étais pas en 4.0u1 au passage et ça a marché) vers ESXI 4.1 (full compatible Windows 2008 et Windows 7…).

    Donc étape pour l’ upgrade :

    -> Activation ssh comme indiqué ici.
    -> Déposer le zip : upgrade-from-esxi4.0-to-4.1.0-0.0.26.02.47-release.zip téléchargé sur site vmware sur un serveur web.

    -> Se connecter en ssh sur son ESXI4.0 et faire :
    esxupdate –bundle http://monserveurweb/upgrade-from-esxi4.0-to-4.1.0-0.0.26.02.47-release.zip update

    -> On reboot on est en ESXI 4.1.

    Attention pour se connecter via le vsphere client il faut la dernière version (Hypervisor) que je suis entrain de télécharger comme un con… avec mon 56 k du boulot….

    Heureusement que Michauko partage ici vim-cmd !! 😉

    A+

    Répondre
  4. michauko

    En version 5, 5.1 et 6.0, il faut stocker ses clefs publiques dans /etc/ssh/keys-root/authorized_keys directement, et hop, pas besoin de bidouiller rc.local ou autre…

    Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.