Windows-Ansible-Zugriff

Nutzen Sie diese Anleitung nur, wenn Sie eine Windows-Maschine über Ansible verwalten möchten und das Zielsystem noch keinen unterstützten Remote-Transport bereitstellt.

Für die meisten Sailwright-Onboarding-Abläufe ist die README der bessere Einstiegspunkt. Für den vom Wrapper verwalteten Localhost-Ablauf beginnen Sie mit Lokales Provisioning. Die folgenden Befehle sind vor allem gedacht für:

• lokale Ansible-Läufe gegen dieselbe Windows-Maschine
• bestehende Windows-Hosts, bei denen der Remote-Zugriff manuell eingerichtet werden muss
• die Fehlerbehebung bei WinRM- oder SSH-Konnektivität

Transport wählen

Windows-Zielsysteme lassen sich über einen der folgenden Transporte erreichen:

• WinRM: nativer für Windows, benötigt aber oft zusätzliche Einrichtung und kann durch Unternehmensrichtlinien eingeschränkt sein
• SSH: in der Regel einfacher zu handhaben, erfordert aber die OpenSSH-Server-Funktion auf der Zielmaschine

Verwenden Sie nur die Option, die Sie tatsächlich benötigen.

Sicherheitshinweis

Bei Localhost-Läufen über sailwright provision local richtet Sailwright das jetzt selbst temporär und sicher auf Windows ein. Der Standard-WinRM-Modus erstellt ein dediziertes lokales Administratorkonto mit einem zufälligen Passwort, aktiviert WinRM über HTTPS auf der Loopback-Adresse für die Dauer des Laufs und stellt beim Aufräumen den vorherigen WinRM-Zustand wieder her. Falls das Konto devalchemy_ansible bereits existiert, verwendet der WinRM-Ablauf es erneut, stellt beim Aufräumen dessen ursprünglichen Status für Aktivierung, Administratorrechte und Beschreibung wieder her und belässt das rotierte Passwort. Die SSH-Alternative (sailwright provision local --proto ssh) erstellt oder aktualisiert ein temporäres lokales Administratorkonto mit einem temporären SSH-Schlüssel und aktiviert oder installiert bei Bedarf den OpenSSH-Server. Für den Lauf setzt sie die Standard-SSH-Shell auf PowerShell und stellt beim Aufräumen den vorherigen SSH-Dienst-, Firewall-, authorized_keys- und Shell-Zustand wieder her. Musste der Wrapper den OpenSSH-Server installieren, deaktiviert das Aufräumen sshd, belässt aber die OpenSSH-Server-Funktion installiert, damit für das Aufräumen kein Neustart erforderlich ist. Falls das Konto devalchemy_ansible bereits existiert, verwendet der SSH-Ablauf es erneut und rotiert dessen Passwort für den Lauf; das vorherige Passwort wird beim Aufräumen nicht wiederhergestellt – reservieren Sie dieses Konto daher für Automatisierung statt für manuelle Anmeldungen.

Auch bei der manuellen WinRM-Einrichtung sollten Sie verschlüsselten Transport bevorzugen. Vermeiden Sie unverschlüsseltes WinRM, außer Sie befinden sich in einer streng kontrollierten Testumgebung und sind sich der damit verbundenen Risiken bewusst.

Option 1: WinRM aktivieren

Für Localhost-Provisioning bevorzugen Sie:

sailwright.exe provision local --check
sailwright.exe provision local

Für die manuelle Verwendung von ansible-playbook richten Sie einen verschlüsselten WinRM-Listener ein und übergeben Sie Ansible Ihre eigenen Zugangsdaten und Verbindungsvariablen.

Option 2: SSH-Server aktivieren

Für Localhost-Provisioning über den Wrapper bevorzugen Sie:

sailwright.exe provision local --proto ssh --check
sailwright.exe provision local --proto ssh --check --yes --force-ssh-uninstall
sailwright.exe provision local --proto ssh

Das vom Wrapper verwaltete Konto devalchemy_ansible ist für Automatisierung gedacht. Falls es bereits existiert, aktualisiert der SSH-Bootstrap dessen Passwort vor dem Lauf, und das Aufräumen belässt dieses rotierte Passwort. Hat der Wrapper den OpenSSH-Server für den Lauf installiert, deaktiviert das Aufräumen sshd, deinstalliert aber nicht die OpenSSH-Server-Funktion.

Installieren Sie für die manuelle Einrichtung den OpenSSH-Server, starten Sie sshd, und setzen Sie die Standard-Shell von OpenSSH auf PowerShell, damit Ansible-Sitzungen nicht auf cmd.exe zurückfallen:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0; `
Start-Service sshd; Set-Service -Name sshd -StartupType 'Automatic'; `
New-Item -Path 'HKLM:\SOFTWARE\OpenSSH' -Force | Out-Null; `
New-ItemProperty -Path 'HKLM:\SOFTWARE\OpenSSH' -Name DefaultShell -Value 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe' -PropertyType String -Force | Out-Null

Wenn Sie die DefaultShell-Einstellung überspringen, kann OpenSSH weiterhin cmd.exe starten, was Ansible-über-SSH-Läufe auf Windows häufig unterbricht.

OpenSSH-Server nach einem Wrapper-Lauf entfernen

Musste sailwright provision local --proto ssh den OpenSSH-Server auf einer Maschine installieren, auf der er noch nicht vorhanden war, belässt das Aufräumen die Funktion installiert. Wenn Sie das manuell rückgängig machen möchten, entfernen Sie die Funktion nach dem Provisioning-Lauf selbst:

Stop-Service sshd -ErrorAction SilentlyContinue
Set-Service -Name sshd -StartupType Disabled -ErrorAction SilentlyContinue
Remove-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

Windows meldet möglicherweise, dass die Funktion erst mit dem nächsten Neustart entfernt wird. Sollte das passieren, starten Sie neu, bevor Sie davon ausgehen, dass der OpenSSH-Server vollständig entfernt ist.

Firewall- und Kontoanforderungen

In beiden Fällen müssen Sie möglicherweise weiterhin eingehende Verbindungen über die lokale Firewall zulassen. Stellen Sie sicher, dass das für Ansible verwendete Konto über Administratorrechte verfügt.

Falls Sie einen dedizierten Benutzer zum Testen benötigen, können Sie einen anlegen – für den Localhost-Wrapper geschieht dies jedoch automatisch:

# Optional: bevorzugen Sie nach Möglichkeit einen bestehenden Administrator-Benutzer
net user ansible 'Secret123!@#' /add; `
net localgroup Administrators ansible /add

Ein Windows-Playbook manuell ausführen

Sobald der Remote-Zugriff verfügbar ist, verwenden Sie die Windows-Beispiele in Playbooks ausführen.