Ansible et Windows : SSH, WinRM et OpenSSH expliqués

Toute cette section a tourné autour de Linux, avec SSH comme canal radio universel. Mais Nordika, comme beaucoup de PME, a aussi des serveurs Windows dans son parc. Est-ce qu’Ansible peut aussi les piloter ?

Réponse courte : oui, mais avec des nuances importantes à connaître avant de foncer.

ℹ️ Cette leçon reste volontairement théorique. On n’a pas de serveur Windows disponible dans nos conteneurs de lab pour la pratiquer en direct — mais les concepts valent la peine d’être connus, ne serait-ce que pour savoir ce qui vous attend le jour où vous devrez automatiser un serveur Windows.

Le mode historique : WinRM

Historiquement, Ansible ne parle pas SSH avec Windows, mais un protocole propriétaire Microsoft : WinRM (Windows Remote Management). Contrairement à SSH, c’est une connexion HTTP/HTTPS qui nécessite :

une collection dédiée : ansible.windows (installable via ansible-galaxy, qu’on détaille en section 6) ;
une configuration spécifique côté Windows (activer WinRM, configurer l’authentification) ;
des variables de connexion différentes dans l’inventaire, comme ansible_connection: winrm.

Concrètement, dans l’inventaire, une machine Windows en WinRM ressemble à ça :

windows_servers:
  hosts:
    win-server-1:
      ansible_host: 10.0.1.50
      ansible_connection: winrm
      ansible_winrm_transport: ntlm
      ansible_port: 5986

C’est fonctionnel, mais ça demande une configuration côté Windows qui n’est pas activée par défaut, et qui a longtemps été perçue (à raison) comme plus lourde à mettre en place que le SSH qu’on utilise partout ailleurs.

L’alternative plus récente : OpenSSH sur Windows

Depuis Windows 10 et Windows Server 2019, Microsoft propose un serveur OpenSSH natif, installable comme fonctionnalité optionnelle de Windows. Et bonne nouvelle : une fois ce serveur SSH activé côté Windows, Ansible peut s’y connecter exactement comme sur un Linux, avec ansible_connection: ssh.

windows_servers:
  hosts:
    win-server-1:
      ansible_host: 10.0.1.50
      ansible_connection: ssh
      ansible_shell_type: powershell

Remarquez le ansible_shell_type: powershell : c’est ce qui indique à Ansible que les commandes brutes (comme raw, vu en 1.5) doivent être interprétées en PowerShell plutôt qu’en shell Unix. Un joli pont avec votre formation PowerShell, d’ailleurs : les modules Windows d’Ansible s’appuient en coulisses sur des scripts PowerShell.

Ce qui ne change pas : les modules dédiés

Que vous passiez par WinRM ou par SSH, les modules classiques (apt, service, user…) ne fonctionnent pas sur Windows : ils sont pensés pour Linux. Il faut utiliser leurs équivalents Windows, comme win_package, win_service, ou win_user, fournis par la collection ansible.windows.

Ce qu’il faut retenir

WinRM reste le mode historique et le plus documenté, mais demande une configuration spécifique côté Windows.
OpenSSH sur Windows permet de rester sur un canal SSH unique pour toute votre flotte, Linux et Windows mélangés — plus cohérent avec tout ce qu’on a vu jusqu’ici.
Dans les deux cas, les modules utilisés sont différents de ceux qu’on va manipuler sur Linux tout au long de cette formation.

Cette formation reste centrée sur Linux — c’est là que se trouve l’essentiel de votre parc, et c’est là qu’Ansible est le plus naturel. Mais maintenant, vous savez que la porte n’est pas fermée côté Windows.

Prochaine étape : le premier TP de la formation, où on lance notre toute première commande ad-hoc sur la flotte Nordika, en conditions réelles sur les conteneurs du lab.