Tags: Windows Server 2019, SSH, WSUS
In der Version 2019 enthält Windows Server erstmals OpenSSH als optionales Feature, was die Installation und Konfiguration vereinfacht. Allerdings verhindern Fehler in einigen Builds des Betriebssystems ein erfolgreiches Hinzufügen des SSH-Servers, und mit WSUS gibt es die gleichen Probleme wie bei den RSAT.
Die Portierung von OpenSSH auf Windows erleichtert das Management von heterogenen Umgebungen. So lassen sich Linux-Rechner über SSH von Windows aus remote administrieren und dank des neuen OpenSSH-Servers funktioniert nun auch der umgekehrte Weg. Zudem unterstützt PowerShell Core das Remoting über SSH, und zwar auch zwischen den verschiedenen OS.
OpenSSH-Server nicht im Lieferumfang des Betriebssystems
Eigentlich würde man erwarten, dass eine Systemkomponente mit solcher strategischen Bedeutung als Bestandteil des Betriebssystems ausgeliefert wird und sich wie gewohnt als Feature über den Server Manager oder PowerShell installieren lässt.
Microsoft hat sich jedoch entschieden, OpenSSH als optionales Feature (auch "Feature on Demand") bereitzustellen. Dadurch vereinheitlicht sich die Installation zwischen Client- und Server-OS. Die folgende Beschreibung gilt mithin auch für Windows 10 ab Release 1803.
Installation über die GUI
Zuständig ist dafür die App Einstellungen, wo man unter Apps dem Link Optionale Features verwalten folgt. Wie man dort an der Liste der installierten Komponenten erkennen kann, ist der SSH-Client standardmäßig bereits installiert. Den Server hingegen ergänzt man über die Option Features hinzufügen.
In der daraufhin angezeigten Liste wählt man den OpenSSH-Server aus und klickt auf die sich dann öffnende Schaltfläche Installieren. Windows lädt nun die benötigten Dateien über das Internet. Tritt ein Fehler auf, dann erhält man in der Regel von der App Einstellungen keine Nachricht, sondern sie springt einfach wieder zurück zur Liste der Features.
OpenSSH-Server über PowerShell hinzufügen
Für mehr Transparenz sorgt dagegen PowerShell, wo man den genauen Namen des benötigten Pakets so ermittelt:
Get-WindowsCapability -Online | ? name -like *OpenSSH.Server*
Anschließend übergibt man diesen an Add- WindowsCapability.
Alternativ reicht man den Output gleich über eine Pipe weiter:
Get-WindowsCapability -Online | ? name -like *OpenSSH.Server* |
Add-WindowsCapability -Online
Fehlerhafte Builds
Hier kann es zumindest aus zwei Gründen zu Problemen kommen. Ist der Build des Systems älter als 17763.194, dann läuft man in den Fehler
Add-WindowsCapability failed. Error code = 0x800f0950
In diesem Fall benötigt man ein aktuelles kumulatives Update, um das Problem zu beheben (es ist hier dokumentiert).
Probleme mit WSUS
Eine weitere Hürde ergibt sich, wenn der Server, wie meistens der Fall, über WSUS mit Updates versorgt wird. Microsoft liefert die Features on Demand nämlich an WSUS vorbei aus, so dass man sie nicht über den internen Update-Server bekommt.
Daher ist es nicht unwahrscheinlich, dass PowerShell hier folgenden Fehler präsentiert:
Fehler bei "Add-WindowsCapability". Fehlercode: 0x8024002e
Im Eventlog findet sich dann ein Eintrag mit der ID 1001, der besagt, dass das OpenSSH-Server-Package nicht vorhanden ist.
Abhilfe schafft wie schon bei den RSAT, dass man Windows über eine Gruppenrichtlinie erlaubt, optionale Features direkt von Microsoft Update zu laden. Sie heißt Einstellungen für die Installation von optionalen Komponenten und die Reparatur von optionalen Komponenten und findet sich unter Computerkonfiguration => Richtlinien => Administrative Vorlagen => System.
Gleichzeitig muss man darauf achten, dass weder die Einstellung Keine Verbindung mit Windows Update-Internetadressen herstellen noch Zugriff auf alle Windows Update-Funktionen deaktivieren in Kraft ist.
Letztere hat man möglicherweise aktiviert, um Benutzer daran zu hindern, Feature-Updates manuell herunterzuladen. Das betrifft in erster Linie Windows 10 und weniger den Server.
SSH-Server aktivieren
OpenSSH-Server installiert zwei Dienste, die aber noch nicht laufen und deren Starttyp zudem manuell bzw. deaktiviert ist. Wenn man SSH regelmäßig nutzen möchte, dann wird man die Services automatisch starten.
Das kann man zwar über die GUI Dienste konfigurieren, am schnellsten geht es aber über PowerShell:
Set-Service sshd -StartupType Automatic
Set-Service ssh-agent -StartupType Automatic
Um den SSH-Server gleich in Betrieb zu nehmen, startet man zusätzlich die beiden Services von Hand:
Start-Service sshd
Start-Service ssh-agent
Mit dem Befehl
Get-Service -Name *ssh* | select DisplayName, Status, StartType
überzeugt man sich, ob die Einstellungen für die zwei Dienste passen und sie erfolgreich gestartet wurden. Nun kann man noch prüfen, ob die Firewall-Regel für eingehende SSH-Verbindungen ordnungsgemäß aktiviert wurde:
Get-NetFirewallRule -Name *SSH*
Verbindung testen
Wenn auch diese Bedingung erfüllt ist, dann steht einem Test nichts mehr im Weg. Von einem Windows-10-PC oder einem Linux-Rechner verbindet man sich dazu mit dem frisch konfigurierten Server:
ssh <Name-des-Servers>
Damit landet man auf der alten Eingabeaufforderung, kann aber dort auch PowerShell starten.
Schließlich sollte man überlegen, ob man aus Sicherheitsgründen die Public-Key-Authentifizierung nutzen möchte. Diese erhöht auch den Benutzerkomfort, weil man kein Passwort mehr eingeben muss. Diese Anleitung beschreibt, wie man dafür vorgeht.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
Weitere Links
5 Kommentare
Für die "FOD" (Features on Demand) gibt es im VLSC auch ISO-Downloads. Da ist das CAB für OpenSSH-Server-Package enthalten.
In welchem ISO finde ich die Cab-Datei?
Im ersten FOD-ISO.
So, merci. Hab's gefunden und mit dism installiert. Da muss man mal drauf kommen, dass der OpenSSH.server Bestandteil des Windows-10-ISOs ist und nicht der Server-ISOs.
...das klappt ja unter win 10 und pubkey auth schon mal ganz gut soweit, nur bekomme ich es einfach nicht hin, einem anderen (admin-) Benutzer den SSH Zugriff zu ermöglichen? Der Server refused immer den Key?