Windows Server 2025 SFTP ermöglicht die verschlüsselte Übertragung von Dateien über den in Windows integrierten OpenSSH-Server. Seit Windows Server 2025 ist die OpenSSH-Komponente nach Microsoft-Dokumentation standardmäßig installiert, aber nicht automatisch als zugänglicher SSH-Dienst aktiviert. Für die IT ist das interessant, wenn Anwendungen Daten regelmäßig zwischen Windows-, Linux- und externen Systemen austauschen. Ein SFTP-Endpunkt muss jedoch deutlich sorgfältiger eingerichtet werden als nur durch das Öffnen von TCP-Port 22. Dieser Leitfaden erklärt Installation, Konten, SSH-Schlüssel, Dateiberechtigungen, Netzwerksegmentierung, Protokollierung und wiederholbare Betriebskontrollen. Der Fokus liegt auf verlässlicher Dateiübertragung mit klar abgegrenzten Rechten.
Autor: Salman Dolatpanah Gortlar · GORTNET · Stand 5. November 2026
Kernregel: Ein SFTP-Server benötigt eigene Konten, beschränkte Verzeichnisse und überprüfte Hostkeys – nicht nur eine offene Firewallregel.
Windows Server 2025 SFTP: Unterschied zu FTP und FTPS
SFTP basiert auf dem SSH-Protokoll und ermöglicht die sichere Dateiübertragung über eine verschlüsselte Verbindung. Es ist nicht identisch mit dem traditionellen FTP oder dessen TLS-geschützter Variante FTPS. Bei SFTP nutzen Authentifizierung, Befehle und Nutzdaten den SSH-Kanal. Daraus ergeben sich andere Firewall- und Integrationsanforderungen. Ein Programm, das nur FTPS unterstützt, kann nicht allein durch das Ändern einer Portnummer automatisch SFTP verwenden.
Definieren Sie deshalb mit jedem Geschäftspartner die tatsächlich unterstützte Technik. Dokumentieren Sie Hostname, Port, Authentifizierungsart, Verzeichnisstruktur und geplante Übertragungszeiten. Ein SFTP-Server für externe Partner sollte nicht zugleich als allgemeine administrative Shell für alle Dienstkonten fungieren. Trennen Sie Dateiübertragung und Systemverwaltung dort, wo die Architektur das erlaubt.
OpenSSH ist installiert, aber nicht zwingend aktiv
Microsoft nennt OpenSSH Server für Windows Server 2025 als standardmäßig installierte Funktion, die separat aktiviert werden kann. Der Dienst heißt typischerweise sshd und kann über den Server Manager oder PowerShell gesteuert werden. Ein installierter SSH-Client auf dem Rechner ist dagegen kein Hinweis, dass ein eingehender SSH-Server erreichbar ist. Prüfen Sie den tatsächlichen Dienststatus, bevor Sie Regeln verändern.
Eine kontrollierte Aktivierung umfasst den Starttyp, die Windows-Firewallfreigabe und die zulässigen Verwaltungsnetze. Vermeiden Sie es, TCP 22 pauschal für das gesamte Internet zu öffnen, wenn nur zwei bekannte Partner eine Verbindung benötigen. Der Betrieb muss zudem mit der Unternehmensrichtlinie für Updates und Härtung abgestimmt werden. OpenSSH ist Teil der Windows-Betriebsumgebung und benötigt genauso Wartung wie IIS oder andere Netzwerkdienste.
sshd_config unter Windows verstehen
Die Windows-spezifische SSH-Serverkonfiguration liegt gewöhnlich unter %ProgramData%\ssh\sshd_config. Microsoft dokumentiert, welche OpenSSH-Optionen unter Windows unterstützt werden und wo Unterschiede zu Linux auftreten können. Ein ungetestetes Kopieren einer Linux-Konfiguration kann wichtige Funktionen deaktivieren oder unerwartete Berechtigungsprobleme verursachen. Änderungen sollten immer auf einer Testinstanz geprüft werden.
Dokumentieren Sie die gewünschte Konfiguration versionskontrolliert und validieren Sie die Syntax vor einem Dienstneustart. Halten Sie den letzten funktionsfähigen Stand bereit. Eine falsch eingestellte Authentication- oder Match-Regel kann auch legitime Wartungszugänge blockieren. Wenn Sie den Dienst remote ändern, muss ein gesicherter unabhängiger Administrationsweg vorhanden sein.
SSH-Schlüssel statt wiederverwendeter Kennwörter
Public-Key-Authentifizierung kann die Abhängigkeit von Passwörtern für automatisierte Dateiübertragungen reduzieren. Jeder Partner oder Dienst sollte möglichst einen eigenen Schlüsselsatz und klar zugeordnete Zugangsrechte erhalten. Private Keys müssen auf dem Client oder in einem geeigneten Secret-Store geschützt sein; auf dem Server wird der autorisierte öffentliche Schlüssel hinterlegt. Eine beliebig gemeinsam genutzte Datei mit Keys unterschiedlicher Partner erschwert Sperrung und Nachvollziehbarkeit.
Die Verwaltung administrativer Windows-Konten unterscheidet sich teilweise von normalen Benutzerkonten. Microsoft beschreibt für Administratoren besondere Standardpfade zur Key-Verwaltung. Übernehmen Sie deshalb keine beliebige Linux-Anleitung ohne Windows-Prüfung. Schützen Sie Dateien und Verzeichnisse mit passenden ACLs. Eine SSH-Schlüsseldatei mit zu breiten Berechtigungen kann von OpenSSH aus Sicherheitsgründen abgelehnt werden.
Lokale Konten, AD-Konten und Serviceidentitäten
Für automatisierte Übertragung kann ein dediziertes Konto mit minimalen Dateirechten sinnvoll sein. Ob ein lokales oder domänengebundenes Konto verwendet wird, hängt vom Sicherheitsdesign und den eingesetzten Anwendungen ab. Ein Domain-Admin-Konto ist für einen normalen SFTP-Import unangemessen. Richten Sie nur die Verzeichnisse und Freigaben ein, die tatsächlich gebraucht werden.
Beachten Sie, dass eine erfolgreiche SSH-Anmeldung noch keinen korrekten Zugriff auf Dateien garantiert. NTFS-Berechtigungen, Gruppenmitgliedschaften und eventuell Netzfreigaben werden unabhängig geprüft. Testen Sie Upload, Download, Löschen und Verzeichniswechsel mit genau dem vorgesehenen Dienstkonto. Nicht benötigte Schreib- oder Löschrechte sollten ausdrücklich entzogen werden.
SFTP-Zugriff auf Verzeichnisse begrenzen
Ein Dateiübertragungsdienst sollte Benutzer nicht ohne fachlichen Grund durch das gesamte Windows-Dateisystem navigieren lassen. OpenSSH bietet je nach unterstützter Plattform und Konfiguration Möglichkeiten, Zugriffe auf bestimmte Subsysteme und Verzeichnisse zu beschränken. Die konkrete Implementierung etwa von Chroot- oder ForceCommand-Regeln muss mit der Windows-spezifischen Dokumentation und dem verwendeten Release geprüft werden.
Verlassen Sie sich nicht allein auf die Anzeige des Startverzeichnisses im SFTP-Client. Entscheidend sind die tatsächlichen NTFS-Rechte und die wirksam konfigurierten Serverregeln. Nutzen Sie Negativtests: Das Konto darf keine fremden Benutzerprofile, Zertifikatsspeicher oder Anwendungsgeheimnisse lesen. Wo eine saubere Isolation nicht praktikabel ist, kann ein separater Server oder eine spezialisierte Managed-File-Transfer-Lösung angemessen sein.
Firewall und Netzwerkarchitektur für SFTP
Ein SFTP-Server benötigt üblicherweise eine SSH-Verbindung über TCP 22, kann aber auch auf einem ausdrücklich vereinbarten anderen Port betrieben werden. Eine abweichende Portnummer ist keine ausreichende Sicherheitsmaßnahme. Entscheidender sind begrenzte Quelladressen, eine geeignete DMZ oder ein dediziertes Transfersegment und die Vermeidung unnötiger Verbindungen aus diesem Segment ins interne Netz.
Ein externer Transferdienst sollte möglichst nicht direkt Domain Controller oder sensible Datenbanksysteme erreichen können. Trennen Sie Uploadverzeichnis und nachgelagerte Datenverarbeitung durch einen kontrollierten Importprozess. Prüfen Sie Dateien vor der Übergabe an Fachanwendungen, und begrenzen Sie mögliche ausgehende Verbindungen. Eine kompromittierte Transferidentität darf nicht automatisch umfassenden Zugriff auf produktive Server erhalten.
Protokollierung und Nachvollziehbarkeit
Für den Betrieb sind erfolgreiche und fehlgeschlagene Anmeldungen, Verbindungsquellen, Übertragungsfehler und Dateiverarbeitungsereignisse relevant. OpenSSH erzeugt unter Windows eigene Ereignisse beziehungsweise Protokolle, abhängig von Version und Konfiguration. Diese Informationen sollten in eine zentrale Monitoringlösung überführt werden, wenn der Transferdienst geschäftskritisch ist.
Ein bloßer Online-Check auf Port 22 sagt nicht aus, ob der erwartete Geschäftsdatensatz verarbeitet wurde. Kombinieren Sie Dienstüberwachung mit Applikationsmetriken: Ist die angekündigte Datei eingetroffen, ist sie vollständig, und wurde sie korrekt importiert? Definieren Sie Aufbewahrungsfristen für Logs und achten Sie darauf, keine Zugangsdaten oder sensiblen Datei-Inhalte unnötig mitzuschreiben.
Host-Key-Prüfung gegen Man-in-the-Middle-Angriffe
Beim ersten Verbindungsaufbau zeigt ein SFTP-Client häufig den Fingerprint des SSH-Hostkeys an. Ein sicherer Prozess überprüft diese Identität über einen unabhängig bestätigten Kanal, bevor sie dauerhaft akzeptiert wird. Wird der Hostkey später unerwartet geändert, darf der Client diese Warnung nicht automatisch ignorieren. Eine legitime Neuinstallation oder Schlüsselrotation muss dokumentiert und mit Geschäftspartnern abgestimmt werden.
Vermeiden Sie Skripte, die jede Hostidentität ungeprüft akzeptieren. Ein solcher Workaround beseitigt einen wesentlichen Schutz des SSH-Protokolls. Planen Sie Schlüsselrotation, Backup der relevanten Konfiguration und einen klaren Kommunikationsprozess für Partner. Auch SFTP über eine TLS-fremde Technik benötigt ein eigenes Identitäts- und Vertrauensmanagement.
SFTP im Hochverfügbarkeits- und Backupkonzept
Bei regelmäßigen Dateitransfers kann ein Ausfall des Servers geschäftskritische Prozesse unterbrechen. Prüfen Sie daher Speicherplatz, Wartungsfenster, Auftragswiederholung und die korrekte Verarbeitung unvollständiger Dateien. Ein sinnvoller Importprozess arbeitet möglichst idempotent und kann eine Übertragung wiederholen, ohne doppelte Geschäftsvorgänge auszulösen.
Sichern Sie die Serverkonfiguration und die für eine Wiederherstellung benötigten öffentlichen Hostidentitäten angemessen. Sensible private Hostkeys müssen geschützt bleiben. Für eine HA-Lösung ist zu klären, wie Hostname, IP-Adresse, Hostkey und Dateiablage beim Wechsel des aktiven Systems konsistent gehalten werden. Ein Load Balancer allein macht eine unstrukturierte SFTP-Ablage noch nicht hochverfügbar.
30-Tage-Hardening-Plan für Windows SFTP
Woche eins: Partner, Datenflüsse, Konten und benötigte Verzeichnisse dokumentieren. Woche zwei: OpenSSH-Testserver konfigurieren, SSH-Keys und minimale NTFS-Rechte einführen. Woche drei: Firewall, Hostkey-Validierung, Negativtests und Transfermonitoring prüfen. Woche vier: Geplante Dateiübertragungen, Fehlerrückläufe, Backup und Wiederherstellung abnehmen.
Nach der Einführung sollten Updates und Zugriffsreviews regelmäßig durchgeführt werden. Ein zuverlässiger Transferdienst muss sowohl die verschlüsselte Verbindung als auch die korrekte Verarbeitung und Abgrenzung der Daten nachweisen. Erst dann ist die SFTP-Schnittstelle ein geeigneter Bestandteil der Unternehmensarchitektur.
Häufige Fragen zu Windows Server 2025 SFTP
Ist OpenSSH Server in Windows Server 2025 vorhanden?
Ja. Microsoft dokumentiert die standardmäßige Installation, aber der Dienst muss für den Zugriff gesondert aktiviert werden.
Ist SFTP dasselbe wie FTPS?
Nein. SFTP verwendet SSH, FTPS ist FTP mit TLS-Schutz.
Sollte man für SFTP Domain-Admin verwenden?
Nein. Verwenden Sie ein eng berechtigtes Dienstkonto und kontrollierte Verzeichnisse.
Reicht es, Port 22 zu öffnen?
Nein. Sie benötigen zudem Identitätsprüfung, Rechtebegrenzung, Monitoring und sichere Transferverarbeitung.
Fazit: SFTP als kontrollierten Unternehmensdienst betreiben
Windows Server 2025 SFTP kann die Dateiübertragung mit externen Partnern vereinfachen. Der Sicherheitsgewinn entsteht durch passende Rechte, saubere Netzwerkgrenzen, stabile Hostidentität und überprüfbare Verarbeitung nach dem Upload.
Weiterführende GORTNET-Artikel
Für die Einrichtung oder Sicherheitsprüfung eines SFTP-Dienstes GORTNET kontaktieren.
Offizielle Microsoft-Quellen
- Microsoft: OpenSSH Overview
- Microsoft: Get Started with OpenSSH Server
- Microsoft: OpenSSH Server Configuration
Stand 5. November 2026. OpenSSH-Optionen und ACL-Verhalten je Betriebssystemversion prüfen.