Windows Server mit OpenSSH für SFTP Server

[dataKEKS 17]

Hallo Freunde der Windows Welt,

 

kennt sich von euch jemand mit dem OpenSSH in Windows aus? Ich kämpfe seit einer Weile immer wieder mal mit der Möglichkeit einen Windows Server als SFTP Server für Backups von Geräten zu nutzen die nur mit SFTP & Keyfile Anmeldung übertragen können.

 

Ich habe mittlerweile einiges am Laufen, aber halt nicht alles :-(

 

Es gibt ja von Microsoft eine recht ausführliche Anleitung mit deren Hilfe ich es sowohl auf Windows Clients als auch Servern schon versucht habe ans Laufen zu bekommen. Tut auch grundlegend, nur die Anmeldung als normaler User will bei mir nur mit Admin Accounts, nicht aber mit normalen Usern.

 

Wenn ich es richtig verstehe sollte eigentlich bei Clients die sich per SSH auf einen entfernten Host verbinden - wenn vorhanden - der lokale Key aus C:\Users\%username%\.ssh genommen werden wenn auf dem Server der Key passend hinterlegt wurde (als authorized_keys).

 

Mache ich das mit einem Win11 Client als SSH Server funktioniert die Anmeldung als User und ich werde nicht mehr nach dem Passwort gefragt, beim Server (momentan Teste ich gegen Server 2025) aber schon :-(

 

Habe die sshd_config schon zwischen Client und Server verglichen, beide haben die Option PubkeyAuthentication yes aktiviert (fehlt ja sonst), aber dennoch verhalten sich Windows Server und Client bei mir unterschiedlich und ich weiß nicht wieso :-(

 

 

Grüße aus BaWü

Norbert

[dataKEKS 17]

Ich habe jetzt mal noch weiter gegraben:

 

- eine Verbindung mit einem Adminkonto über ssh -i id_ecdsa -l user@domainfqdn host funktioniert

- eine Verbindung mit einem nicht Adminkonto (Backup) über ssh -i id_ecdsa -l backup@domainfqdn host funktioniert nicht

 

Fehlermeldung: Permission denied (publickey,keyboard-interactive)

 

Fehlt dem Benutzer Backup das Recht zur Interaktiven Anmeldung? Kann das die Ursache sein?

 

 

Norbert

[cj_berlin 1.578]

Moin,

 

welche Anmeldenrechte hat denn der Nicht-Adminuser auf der Maschine? Ich meine, in einem der beiden Szenarien braucht man lokale Anmeldenrechte.

Das könnte auch den Unterschied Client OS vs. Server OS erklären...

[dataKEKS 17]

Er ist aktuell weder auf Client noch Server Admin, wirklich stumpfer User :-)

[testperson 1.988]

Moin,

 

andere Frage wäre, ob sich hier die Energie lohnt. Bei Bitvise bekommst du das ab $99,95 pro Installation (ggfs. + $79,80 für 5 Jahre Upgrade access).

 

Gruß

Jan

[dataKEKS 17]

Hallo Jan,

 

ich verstehe vollkommen was Du meinst, ich kämpfe halt immer wieder mit den dauerklammen Schulfinanzen, das ganze dann noch gepaart mit dem Technikerspieltrieb (das muss doch auch mit Bordmitteln gehen - oder nicht?), aber berechtigt ist die Frage.

 

Hätte eigentlich gedacht mit OpenSSL als Basis eigentlich gefühlt den Standard schlecht hin nutzen zu können?

 

Norbert

[cj_berlin 1.578]

vor 2 Stunden schrieb dataKEKS:

Er ist aktuell weder auf Client noch Server Admin, wirklich stumpfer User

das war nicht die Frage

[dataKEKS 17]

vor 26 Minuten schrieb cj_berlin:

das war nicht die Frage

Dann verstehe ich Dich nicht, ist ein Domänen Benutzer in einem nackten Test ohne jeglichen Sonderrechte

[Nobbyaushb 1.684]

vor 3 Minuten schrieb dataKEKS:

Dann verstehe ich Dich nicht, ist ein Domänen Benutzer in einem nackten Test ohne jeglichen Sonderrechte

Ich misch mich mal ein, so wie ich das verstanden habe sollte das ein lokaler User auf dem Server sein, mit passenden Rechten

Ob das mit einem Domänen-User mit passenden Rechten geht weiß ich nicht 

 

[dataKEKS 17]

Kennt von euch jemand eine Anleitung in der das Thema Rechte von OpenSSH unter Windows erklärt wird? Mir ist bislang noch nichts erleuchtendes untergekommen :-(

[cj_berlin 1.578]

Vergleiche mal die Ausgabe von

 

whoami /privs

 

von dem nicht-Admin auf Server und Client. Ich hatte das mal untersucht, und es ist eine andere Art von Login: https://it-pro-berlin.de/2024/07/use-ssh-on-windows-they-said/

bearbeitet 10. Februar von cj_berlin

[dataKEKS 17]

vor 12 Minuten schrieb cj_berlin:

Vergleiche mal die Ausgabe von

 

wboami /privs

 

von dem nicht-Admin auf Server und Client. Ich hatte das mal untersucht, und es ist eine andere Art von Login: https://it-pro-berlin.de/2024/07/use-ssh-on-windows-they-said/

Ich merk schon - Dein Gedächtnis ist der Hammer... 

Werfe mein Testnetz an sowie ich daheim bin, Update folgt heute noch

 

whoami /priv? Kannte ich auch noch nicht, gleich mal notieren

 

Danke WOL konnte ich mein Lappi gerade mal anwerfen und kann folgendes berichten:

 

1.) Memberserver 2025 mit User Backup

2.) Domain Joined Windows 11 Pro

 

Das deckt sich also mit Deiner Vermutung der unterschiedlichen Rechte auf Client und Server

Ich dreh durch!!! Habe ganz strack gerade mal bei Tante Google nach folgendem gesucht:

 

welche rechte braucht ein user um sich per ssh an einem windows server anzumelden

 

Und damit bin ich gerade endlich weiter gekommen!!! Denn dann kam folgendes:

 

Kaum habe ich die Gruppe der OpenSSH Users angelegt funktionierte die Anmeldung! Die Zugehörigkeit zur Gruppe der Remotedesktopbenutzer scheint aber nicht zu stimmen, ich habe den Backup User wieder aus der Gruppe geworfen und die Anmeldung funktioniert weiter

 

Werde noch weiter testen, aber es geht endlich vorran!

 

 

Norbert

[dataKEKS 17]

Habe jetzt noch mal genauer nachgesehen und das ganze auf einem Windows Server 2025 frisch aufgesetzt, meine anderen Tests waren glaub auch mal mit einem 2022er, aber das Notebook ist gerade auf dem Weg zur Reparatur, also kann ich nicht direkt nachsehen....

 

Es ist faszinierend wie unterschiedlich die Unterlagen zum Thema OpenSSH auf Windows Server sind, habe nach dem Tip von Google mir noch mal meine sshd_config angesehen die frisch erzeugt wurde und da gibt es wirklich die Zeile AllowGroups administrators "openssh users" was das Verhalten auf dieser VM erklärt. Bislang hatte ich aber auch nie den SSH Server über den Server Manager aktiviert sondern per Powershell.....

 

Merke: Je nach OS Version und verwendetem Weg unterscheiden sich die Wege zur Einrichtung und die Rechte ungemein....

 

Aktiviere jetzt mal schnell die PubkeyAuthentication und teste weiter....

[dataKEKS 17]

Also: SSH und SFTP mit einem Windows Server sind gar kein Problem, sowohl mit der von Microsoft direkt mitgelieferten Version beim Windows Server 2025 als auch bei den Vorgängern (und da als optionales Feature).

 

Ich versuche nicht einen kompletten Roman zu schreiben sondern nur ein paar wichtige Stichworte:

- Egal ob Server 2025 oder älter, die Einrichtung aktiviert nicht beide Dienste die zur Key-based authentication erforderlich sind, ebenso wenig passt die Firewall Regel so der Server Mitglied einer Domäne ist,

 

# OpenSSH SSH Server als auf Startart automatisch setzen und starten

Get-Service -Name sshd | Set-Service -StartupType Automatic

Start-Service sshd

# OpenSSH Authentication Agent als auf Startart automatisch setzen und starten

Get-Service ssh-agent | Set-Service -StartupType Automatic

Start-Service ssh-agent

# Firewall so anpassen das nur dann Verbindungen möglich sind wenn die Firewall des Servers im Domänenprofil ist

Set-NetFirewallRule -Name OpenSSH-Server-In-TCP -Enabled True -Profile Domain
 

Damit ist vom Server alles fertig, alles andere sind Einstellungen (sshd_config unter %programdata%\ssh), Filesystem Rechte für die Benutzer und Keys.

 

Was super funktioniert und genau mein Thema seitens der Rechte sauber abbildet: Es gibt die Möglichkeit mit zwei Zeilen die Rechte pro Benutzer sauber einzuschränken:

Match User %domain%\%username%
ChrootDirectory "%drive%\%path%"

 

Das pro User eingetragen (und danach den Dienst gestartet für dazu das der User nicht mehr unter c:\users\%username% landet sondern in dem zuvor definierten Pfad und von da aus nur in Unterordner, nicht aber in die übergeordneten Laufwerke. Wichtig hierbei natürlich: Der Benutzer sollte auch Schreibrechte in dem Pfad haben wenn er Uploads durchführen soll..

 

Noch zwei ganz wichtige Anmerkungen:

- die sshd_config ist Case Sensitiv, als Groß- und Kleinschreibung beachten, und Änderungen an ihr werden erst mit Neustart vom Dienst sshd übernommen

- per Default können sich nur Administratoren verbinden, wenn es wie in meinem Fall bewusst mit normalen Benutzern laufen soll braucht man dazu mindestens eine Gruppe, diese wird beim Server 2025 zwar angelegt, nur bei einer deutschsprachigen Version leider eingedeutscht während die Konfiguration vom OpenSSH Server den originalen, englischen Namen verwendet. Ihr könnt hier sowohl die Gruppe umbenennen oder die Konfiguration anpassen, nur eins von beidem ist dann halt doch zwingend erforderlich....

 

Wie vermutlich jedem von uns ist mir bei diesem Thema eins sehr leidvoll aufgefallen: Viele Anleitungen geben nur Bruchstücke wieder, und die übersetzten Artikel sind immer wieder stark "verzerrt" und damit teilweise falsch, also wenn ihr sucht: Kämpft euch besser durch das englische Original, es schont die Nerven!

 

Norbert