Windows-Ansible-Zugriff

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

Für die meisten Einstiege in Sailwright ist die Haupt-README der bessere Startpunkt. 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 denselben Windows-Rechner
• bestehende Windows-Hosts, die manuell für den Remote-Zugriff eingerichtet werden müssen
• die Fehlersuche bei WinRM- oder SSH-Verbindungen

Transport wählen

Windows-Ziele sind über einen dieser beiden Transporte erreichbar:

• WinRM: näher an Windows, erfordert aber oft zusätzliche Einrichtung und kann durch Unternehmensrichtlinien eingeschränkt sein
• SSH: meist leichter nachzuvollziehen, setzt aber die Funktion OpenSSH Server auf dem Zielrechner voraus

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

Sicherheitshinweis

Bei Localhost-Läufen über sailwright provision local übernimmt Sailwright unter Windows die vorübergehende, sichere Einrichtung für Sie. Der Standardmodus mit WinRM legt ein dediziertes lokales Administratorkonto mit zufälligem Passwort an, 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. Existiert das Konto devalchemy_ansible bereits, verwendet der WinRM-Ablauf es weiter, stellt beim Aufräumen den ursprünglichen Zustand (aktiviert, Administratorrechte, Beschreibung) wieder her und belässt das geänderte Passwort. Die SSH-Alternative (sailwright provision local --proto ssh) legt ein vorübergehendes lokales Administratorkonto mit einem temporären SSH-Schlüssel an oder aktualisiert es, aktiviert oder installiert bei Bedarf den OpenSSH Server, setzt die Standard-Shell für SSH für die Dauer des Laufs auf PowerShell. Beim Aufräumen stellt Sailwright den vorherigen Zustand von SSH-Dienst, Firewall, authorized_keys und Shell wieder her. Musste der Wrapper den OpenSSH Server installieren, deaktiviert das Aufräumen sshd, lässt die Funktion OpenSSH Server aber installiert, damit dafür kein Neustart nötig ist. Existiert das Konto devalchemy_ansible bereits, verwendet der SSH-Ablauf es weiter und ändert sein Passwort für den Lauf; das vorherige Passwort wird beim Aufräumen nicht wiederhergestellt. Reservieren Sie dieses Konto daher für die Automatisierung und melden Sie sich damit nicht manuell an.

Auch bei der manuellen WinRM-Einrichtung sollten Sie verschlüsselten Transport bevorzugen. Vermeiden Sie unverschlüsseltes WinRM, es sei denn, Sie arbeiten in einer streng kontrollierten Testumgebung und kennen das Risiko, das Sie eingehen.

Option 1: WinRM aktivieren

Für das Provisioning auf dem lokalen Rechner empfiehlt sich:

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

Wenn Sie ansible-playbook manuell verwenden, richten Sie einen verschlüsselten WinRM-Listener ein und übergeben Sie Ansible Ihre eigenen Zugangsdaten und Verbindungsvariablen.

Option 2: SSH-Server aktivieren

Für das Provisioning auf dem lokalen Rechner über den Wrapper empfiehlt sich:

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 die Automatisierung gedacht. Existiert es bereits, aktualisiert der SSH-Bootstrap sein Passwort vor dem Lauf, und das Aufräumen belässt das geänderte Passwort. Hat der Wrapper den OpenSSH Server für den Lauf installiert, deaktiviert das Aufräumen sshd, deinstalliert aber nicht die Funktion OpenSSH Server.

Installieren Sie bei manueller 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

Lassen Sie die Einstellung DefaultShell weg, kann OpenSSH weiterhin cmd.exe starten, was Ansible-über-SSH-Läufe unter Windows häufig scheitern lässt.

OpenSSH Server nach einem Wrapper-Lauf entfernen

Musste sailwright provision local --proto ssh den OpenSSH Server auf einem Rechner installieren, auf dem er noch nicht vorhanden war, belässt das Aufräumen die Funktion installiert. Möchten Sie das manuell rückgängig machen, 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 das Entfernen der Funktion unter Umständen als ausstehend bis zum nächsten Neustart. Ist das der Fall, 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 eventuell eingehende Verbindungen in der lokalen Firewall zulassen. Stellen Sie sicher, dass das für Ansible verwendete Konto Administratorrechte hat.

Benötigen Sie einen dedizierten Benutzer für Tests, können Sie einen anlegen. Beim Localhost-Wrapper geschieht das jedoch automatisch:

# Optional: prefer an existing admin user when possible
net user ansible 'Secret123!@#' /add; `
net localgroup Administrators ansible /add

Windows-Playbook manuell ausführen

Sobald der Remote-Zugriff möglich ist, finden Sie die Windows-Beispiele unter Playbooks ausführen.