SSH-Schlüssel Windows erstellen und per SSH auf Server anmelden

In vielen Windows-Umgebungen bietet die OpenSSH Authentifizierung unter Windows eine sichere Alternative zu herkömmlichen Passwörtern. Eine schlüsselbasierte Authentifizierung mit OpenSSH bietet eine bewährte Alternative: Sie verwenden ein private/public Schlüsselpaar statt Passwörter, was die Angriffsfläche deutlich reduziert. In diesem Beitrag erfahren Sie, wie Sie unter Windows ein Schlüsselpaar erzeugen, den SSH-Agenten sinnvoll nutzen und den öffentlichen Schlüssel sicher auf Server mit authorized_keys übertragen. Die Schritte orientieren sich an der Microsoft/OpenSSH-Dokumentation und praktischen Best Practices.

Hinweis zu AuthorizedKeysCommand und AuthorizedKeysCommandUser

OpenSSH unter Windows unterstützt nicht alle Linux-spezifischen Direktiven. Besonders wichtig: AuthorizedKeysCommand und AuthorizedKeysCommandUser werden nicht unterstützt. Das bedeutet, dass Sie SSH-Schlüssel nicht dynamisch aus Active Directory abrufen können. Verwenden Sie stattdessen statische authorized_keys-Dateien. Diese Einschränkung ist entscheidend, wenn Sie eine zentrale oder domänenweite Schlüsselverwaltung planen.

Wenn Sie sich erst einmal mit dem Thema Schlüssel arbeiten, lohnt sich ein Blick auf verwandte Ansätze wie Identitäts-Provider und Passphrase-gestützte Anmeldungen. In unseren Beiträgen zu Authentik vs. Keycloak sowie zur Identity-Management-Strategie finden Sie weiterführende Perspektiven.

OpenSSH Authentifizierung unter Windows Schritt für Schritt

Schlüsselpaare bestehen aus zwei Dateien: einem privaten Schlüssel (sollte geschützt bleiben) und einem öffentlichen Schlüssel (wird auf dem SSH-Server hinterlegt). Die Authentifizierung vergleicht den öffentlichen Schlüssel mit dem privat bereitgestellten Schlüssel des Benutzers. Fehlt der passende Private-Key oder ist er nicht vorhanden, schlägt die Anmeldung fehl. Die Passphrase des privaten Schlüssels erhöht die Sicherheit nochmals, da sie die Nutzung des Schlüssels zusätzlich absichert.

Privater Schlüssel: bleibt auf dem Client, geschützt durch Passphrase.
Öffentlicher Schlüssel: wird auf dem Server hinterlegt (authorized_keys oder Administrator-Authorized Keys).
Wichtig: Wenn jemand den privaten Schlüssel in die Hände bekommt, kann diese Person sich so authentifizieren – daher gilt: Schlüsselpaar absolut sicher verwahren.

In diesem Beitrag fokussieren wir uns auf die praktischen Schritte unter Windows, damit Sie direkt loslegen können.

Voraussetzungen und Architektur

Bevor Sie loslegen, sollten Sie sicherstellen, dass OpenSSH auf dem Windows-Server installiert ist. Der sshd-Dienst muss laufen, und der Pfad für Hostschlüssel liegt in der Regel unter C:\ProgramData\ssh. Der Dienst kann so konfiguriert werden, dass er beim Systemstart automatisch startet. Ein typischer Ablauf sieht so aus:

OpenSSH-Server installieren (Windows OpenSSH-Server).
sshd als Dienst automatisch beim Start starten lassen.
Hostschlüssel werden standardmäßig in C:\ProgramData\ssh gespeichert.

Für Clients generieren Sie Schlüsselpaare mit ssh-keygen. Als Standardalgorithmus wird oft Ed25519 verwendet, aber es gibt auch Optionen wie RSA oder ECDSA – je nach Sicherheitsanforderung. Im Beispiel verwenden wir hier ECDSA explizit, um die Schritte nachvollziehbar zu machen.

Hinweis: OpenSSH auf Windows unterscheidet sich in der Handhabung mancher Linux-Direktiven. Die hier beschriebenen Konfigurationsschritte sind praxisnah und stabil, wenn Sie sich an die genannten Pfade und Dateien halten.

Hostschlüssel generieren

Hostschlüssel schützen das SSH-Server-Zertifikat. Windows-OpenSSH erzeugt diese Schlüsseldateien beim ersten Start des sshd-Dienstes automatisch, sofern der Dienst läuft. Standardmäßig müssen Sie den sshd-Dienst manuell starten, um ihn so zu konfigurieren, dass er beim Neustart automatisch gestartet wird.

Vergewissern Sie sich, dass der sshd-Dienst installiert ist.
Öffnen Sie eine PowerShell-Sitzung mit Administratorrechten und führen Sie aus:

# Set the sshd service to be started automatically.
Get-Service -Name sshd | Set-Service -StartupType Automatic

# Start the sshd service.
Start-Service sshd

Nach dem ersten Start werden Hostschlüssel unter C:\ProgramData\ssh erzeugt. Dieser Speicherort ist der Standardpfad für Hostschlüssel in der Windows-OpenSSH-Umgebung.

Generierung des Benutzerschlüssels

Auf dem Client benötigen Sie ein Schlüsselpaar. Verwenden Sie dazu ssh-keygen.exe. Sie können verschiedene Algorithmen angeben: DSA, RSA, ECDSA oder Ed25519. Wird kein Algorithmus gewählt, verwendet ssh-keygen Ed25519 standardmäßig. Für unser Beispiel erzeugen wir ein ECDSA-Schlüsselpaar:

ssh-keygen -t ecdsa

Die Abfrage führt Sie durch den Speicherort der Schlüsseldateien. Standardpfad ist

Privater Schlüssel: C:\Users\Benutzername.ssh\id_ecdsa
Öffentlicher Schlüssel: C:\Users\Benutzername.ssh\id_ecdsa.pub

Sie werden außerdem nach einer Passphrase gefragt. Die Passphrase schützt den privaten Schlüssel zusätzlich. In vielen Umgebungen lohnt sich eine Passphrase – in rein automatisierten Abläufen kann man sie auch leer lassen, was jedoch das Sicherheitsniveau mindert.

Nach Abschluss verfügen Sie über ein Public/Private Key-Paar. Der öffentliche Schlüssel wird später auf dem Server hinterlegt.

Um den privaten Schlüssel sicher zu speichern und den Zugriff durch den SSH-Agenten zu erleichtern, konfigurieren Sie ssh-agent und laden dort den privaten Schlüssel…

# By default, the ssh-agent service is disabled. Configure it to start automatically.
Get-Service ssh-agent | Set-Service -StartupType Automatic

# Start the service.
Start-Service ssh-agent

# The following command should return a status of Running.
Get-Service ssh-agent

# Load your key files into ssh-agent.
ssh-add $env:USERPROFILE\.ssh\id_ecdsa

Dieses Vorgehen speichert den privaten Schlüssel sicher im Kontext Ihres Windows-Kontos. Wichtig: Bewahren Sie den privaten Schlüssel sicher auf und löschen Sie ihn nicht unnötig vom lokalen System, solange er im ssh-agent geladen ist. Verlust des privaten Schlüssels erfordert die Neugenerierung eines Schlüsselpaares und eine anschließende Aktualisierung des öffentlichen Schlüssels auf allen Servern, mit denen Sie interagieren.

Hinweis: Das automatische Speichern von privaten Schlüsseln im SSH-Agent ermöglicht eine bequeme, passphrase-gestützte Nutzung, ohne das Passwort jedes Mal eingeben zu müssen. Der Schutz bleibt bestehen, solange die Passphrase zusammen mit dem Schlüssel genutzt wird.

Bereitstellen des öffentlichen Schlüssels auf dem Server

Um die Authentifizierung zukünftig mit dem Schlüssel durchzuführen, müssen Sie den Inhalt des öffentlichen Schlüssels (.ssh\id_ecdsa.pub) auf dem Server in eine Textdatei einfügen. Der Dateiname und Speicherort hängen davon ab, ob das Benutzerkonto Standard- oder Administratorkonto ist.

Standardbenutzer

Kopieren Sie den öffentlichen Schlüssel in eine Datei namens authorized_keys im Verzeichnis C:\Users\username.ssh\ auf dem Server. Sie können dazu SCP oder PowerShell verwenden, um den Schlüssel remote zu schreiben. Ein Beispiel (Remote-Transfer per PowerShell) sieht so aus, wobei username durch Ihren echten Benutzernamen ersetzt wird:

# Öffentlichen Schlüssel auf dem Client lesen
$authorizedKey = Get-Content -Path $env:USERPROFILE\.ssh\id_ecdsa.pub

# Remote-Befehl zum Erstellen des .ssh-Verzeichnisses und Hinzufügen des Schlüssels
$remotePowershell = "powershell New-Item -Force -ItemType Directory -Path $env:USERPROFILE\.ssh; Add-Content -Force -Path $env:USERPROFILE\.ssh\authorized_keys -Value '$authorizedKey'"

# Remote ausführen (SSH-Verbindung zum Server)
ssh username@contoso.com $remotePowershell

Der Zugriff erfolgt über den privaten Schlüssel, der dem Server-User zugeordnet ist.

Administrativer Benutzer

Für Administratorkonten benötigt man oft eine zentrale Datei Administrators_Authorized_Keys. Diese liegt dann in C:\ProgramData\ssh\administrators_authorized_keys und hat spezielle ACLs. Der öffentliche Schlüssel wird dort eingefügt und die ACL entsprechend gesetzt, damit nur Administratoren und SYSTEM Zugriff erhalten. Beispielcode:

# Öffentlichen Schlüssel wie oben vorbereiten
$authorizedKey = Get-Content -Path $env:USERPROFILE\.ssh\id_ecdsa.pub

# Remote-Befehl zum Kopieren in administrators_authorized_keys und ACL-Anpassung
$remotePowershell = "powershell Add-Content -Force -Path $env:ProgramData\ssh\administrators_authorized_keys -Value '''$authorizedKey''';icacls.exe \"$env:ProgramData\ssh\administrators_authorized_keys\" /inheritance:r /grant \"Administrators:F\" /grant \"SYSTEM:F\""

# Remote ausführen
ssh username@contoso.com $remotePowershell

Hinweis zu SID-basierten Berechtigungen

Wenn Sie in einer nicht-englischen Windows-Umgebung arbeiten, sollten Sie Berechtigungen über SIDs statt Gruppennamen zuweisen. Das vermeidet Probleme mit lokalisierten Gruppennamen.
Beispiel:

C:\ProgramData\ssh\administrators_authorized_keys" /inheritance:r /grant *S-1-5-32-544:F /grant "SYSTEM:F

Die SID S-1-5-32-544 steht hier für die Administratorengruppe und ist sprachunabhängig.

Praktische Tipps und Best Practices

Verwenden Sie bei Moderations- oder Admin-Konten die zentrale Administrator-Authorized Keys-Datei, um Berechtigungen zuverlässig zu steuern.
Die OpenSSH Authentifizierung unter Windows reduziert die Angriffsfläche erheblich, da keine schwachen Kennwörter mehr verwendet werden.
Legen Sie eine Passphrase für Ihre privaten Schlüssel fest, um auch bei Kompromittierung des Speichers eine zusätzliche Schutzebene zu haben.
Vermeiden Sie das Ablegen von privaten Schlüsseln in freigegebenen Verzeichnissen oder auf gemeinsam genutzten Maschinen.
Wenn Sie Ihre SSH-Schlüsselverwaltung langfristig in eine zentrale Identity-Management-Strategie einbetten möchten, lohnt sich ein Blick auf moderne Lösungen wie Authentik oder Keycloak. Beide unterstützen Single Sign-On (SSO), rollenbasierte Zugriffssteuerung und API-basierte Verwaltung von Identitäten. Einen detaillierten Vergleich finden Sie in unserem Artikel Identity-Provider-Vergleich: Authentik vs. Keycloak.

Troubleshooting-Checkliste

Ist sshd läuft und automatisch gestartet beim Systemstart? Prüfen Sie per PowerShell: Get-Service -Name sshd.
Liegen Hostschlüssel im Verzeichnis C:\ProgramData\ssh? Falls nicht, generieren Sie sie beim ersten Start des sshd.
Haben Sie den öffentlichen Schlüssel korrekt in authorized_keys hinterlegt? Der Dateiname muss strictly authorized_keys lauten (bei Standardbenutzerkonto im Benutzerverzeichnis).
Sind Berechtigungen der Dateien korrekt gesetzt? Windows verwendet ACLs; bei Administrator-Keys ist die Datei administrators_authorized_keys zu beachten.

Weiterführende Ressourcen (verwandte Inhalte direkt verknüpft)

Um Passwort-basierte SSH-Anmeldung maximal zu vermeiden, lesen Sie unseren Beitrag SSH-Login per Passwort deaktivieren – nur noch mit SSH-Key erlaubt. Dort finden Sie konkrete Schritte zur Deaktivierung von Passwörtern in SSH-Umgebungen und wie Sie sicherstellen, dass Schlüssel zuverlässig funktionieren.
SSH-Login per Passwort deaktivieren – nur noch mit SSH-Key erlaubt
Für strategische Entscheidungen zur Identity-Verwaltung und Authentifizierungslösungen empfehlen wir unseren Artikel Authentik Identity-Management und Authentifizierungssystem. Er erklärt, wie Identity-Provider-Ansätze funktionieren und wann sie sinnvoll sind.
Authentik Identity-Management und Authentifizierungssystem
Wer sich grundsätzlich mit Identity-Providern befasst, kann den Vergleich Authentik vs Keycloak heranziehen. Dort finden Sie Kriterien für die Auswahl eines Identity-Providers in modernen IT-Umgebungen.
Identity-Provider-Vergleich Authentik vs Keycloak

Darüber hinaus bieten wir Ihnen umfassende Unterstützung rund um Ihre Server- und Sicherheitsinfrastruktur. Wenn Sie eine professionelle Beratung oder konkrete Implementierung benötigen, werfen Sie gern einen Blick auf unsere Dienstleistungen oder kontaktieren Sie uns direkt. Weitere Informationen finden Sie unter unserem Leistungsangebot oder über das Kontaktformular.

Für weiterführende Inhalte empfehlen wir außerdem, regelmäßig unsere Blog-Beiträge zu relevanten IT-Security- und Infrastrukturthemen zu lesen, um up-to-date zu bleiben. Sie finden dort praxisnahe Tiefe zu Themen rund um OpenSSH, Schlüsselverwaltung und sicheres Serverzugriffs-Management.

Wenn Sie bei der Umsetzung Unterstützung benötigen, helfen wir Ihnen gerne weiter. Unsere Experten stehen bereit, um Ihre SSH-Infrastruktur sicher aufzubauen, zu testen und langfristig zu betreuen. Besuchen Sie dafür unsere Startseite oder melden Sie sich direkt über Kontakt.