Die Aufgabenstellung war einfach: Es sollten möglichst einfach Daten von mehreren iPads in Verzeichnisse auf einem Windows-Server übertragen werden. Auf Grund der Einfachheit in der Bedienung fiel auf iPad-Seite die Wahl auf ein SFTP-Programm und damit auf das SFTP-Protokoll. Es musste also nun ein SFTP-Server für Windows gefunden werden.

Nun ist die Auswahl von SFTP-Servern unter Windows sehr klein. Die englische Wikipedia zählt 5 OpenSource und 3 Freeware-SFTP-Server auf. Da der SFTP-Server als Dienst laufen und noch in aktiver Entwicklung sein soll und ferner für beliebig viele Nutzer frei verfügbar sein soll, bleibt nur COPSSH als Server übrig.

Die Installation lief einfach und problemlos durch – aber:

  • Der Server, auf dem das SFTP-Service laufen soll, ist Terminalserver und Domänencontroller.
  • Die Benutzernamen enthalten Leerzeichen.

Das bei COPSSH mitgegebene Administrationsprogramm ist für die Verwaltung der Konfiguration nicht sinnvoll: Es wird vom Entwickler für komplexe Konfigurationen nicht empfohlen und in der Tat, seine Fähigkeiten sind hierfür nicht ausreichend. Vielmehr sollte das Programm nicht genutzt werden, da es eine eigene Konfigurationsdatei schreibt und die Standardkonfigurationsdateien des Dienstes überschreibt.

Der Dienst hat eine gute Funktion: Es ist keine komplett eigene Benutzerverwaltung notwendig, vielmehr greift der Dienst für die Passwortabfrage auf das Active-Directory zu. Auf diese Weise müssen Benutzer bei Passwortänderungen kein weiteres Passwort verwalten. Die Passwort-Datei des SSH-Dienstes, passwd im Verzeichnis etc, ist somit eine Mapping-Datei, die die Anmeldenamen am Dienst der Windows-SSID des Active-Directory zuordnet.

Nun tritt jedoch die oben geschilderte Problematik der von uns betreuten Installation zu Tage: Die Benutzernamen enthalten Leerzeichen, diese sind somit für die SSH- oder SFTP-Anmeldung nicht geeignet. Da die Benutzerwaltung jedoch, wie oben beschrieben, auf dem Active-Directory beruht, können keine vom AD getrennten Benutzer angelegt werden. Durch das erwähnte Mapping können jedoch beliebige SSH-/SFTP-Anmeldenamen gewählt werden. Leider ist der Aufbau der Konfigurationsdateien nicht dokumentiert, dies soll nun hier etwas nachgeholt werden.

  • Zuerst wird die SSIDs der Benutzer benötigt, die Zugriff auf das System erhalten sollen. Diese SSIDs können z.B. mit dem Programm psgetsid aus der Sysinternals-Suite ermittelt werden.
  • Die Zeilen der passwd-Datei sind dann wie folgt aufgebaut:
(1):(2):(3):(4):(5),(6)\(7),(8):(9):(10)
  • 1: Unix-Benutzername, also der Name der beim Unix-Login angegeben wird
  • 2: Text „unused“, Bedeutung ist nicht bekannt
  • 3: fortlaufende Unix-Benutzer-ID
  • 4: Gruppen-ID des Benutzers. Diese ID muss in der Datei „group“ definiert sein, sonst ist keine Anmeldung möglich
  • 5: entspricht dem Unix-Anmeldenamen, dieser Eintrag scheint aber nicht ausgewertet zu werden
  • 6: Aufbau ist U-Domänennamen, dieser Eintrag scheint aber nicht ausgewertet zu werden
  • 7: entspricht dem Unix-Anmeldenamen, dieser Eintrag scheint aber nicht ausgewertet zu werden
  • 8: Windows-SSID des Windows-Benutzers. Mit diesem Benutzer wird auf Windows-Seite gearbeitet und dessen Passwort wird auch genommen und dieser Benutzer wird für die realen Zugriffsrechte genutzt.
  • 9: Home-Verzeichnis des Unix-Benutzers, das Mapping erfolgt über die fstab-Datei
  • 10: Shell des Benutzers
  • Soll ein Benutzer das System nutzen können, ist der Shell-Eintrag auf /bin/bash zu setzen, andernfalls auf /bin/false
  • Die Group-Datei etc\group ist wie folgt aufgebaut:
Anzeigename:Windows-SSID:Unix-ID:
  • Die Fstab-Datei, die die Windows-Verzeichnisse den Unix-Konventionen zuordnet, ist etc\fstab und stringent aufgebaut; sie kann einfach erweitert werden.
  • In der SSHD-Konfigurationsdatei, etc\ssd_config, ist schließlich definiert, ob die einzelnen Benutzer sich mit Passwort und / oder mit Key anmelden können, wieviele Sessions erlaubt sind etc. Der Kopfbereich lautet
Port 22
Compression delayed
LogLevel INFO
TCPKeepAlive yes
LoginGraceTime 120
Protocol 2
MaxAuthTries 6
MaxSessions 10
Subsystem sftp internal-sftp -l ERROR
  • die einzelnen Benutzer werden wie folgt eingetragen
Match User benutzername
	PasswordAuthentication   yes
	PubkeyAuthentication   yes
	AllowTcpForwarding   yes
	MaxSessions 10
  • bei „Benuzername“ können Wildcards angegeben werden.
  • Wird eine Zeile „ForceCommand /cygdrive/c/windows/system32/cmd.exe“ eingefügt, so wird beim Anmelden die Windows-Konsole gestartet.
  • Beim Parameter „internal-sftp“ wird nur SFTP zugelassen.
  • Beim Parameter „/bin/bash –login -i“ wird eine Linux-Shell gestartet
  • Beim Parameter „/bin/false“ ist kein Login und kein SFTP möglich.
  • Ist die Zeile nicht vorhanden, kann SFTP und die Linux-Shell benutzt werden.
  • Es können auch andere Programme an Stelle von „cmd.exe“ eingetragen werden, die dann beim Login gestartet werden.
  • Soll ein Benutzer nicht nur SFTP nutzen können, sondern auch einen Shell-Login erhalten, so muss er das Recht bekommen, sich auf dem Rechner anmelden zu können. Hierzu ist die lokale Gruppenrichtlinie anzupassen und das Recht „Lokales Anmelden zulassen“ zu erteilen. Bei einem Domänencontroller wie in unserem Fall, ist dieses Recht nur über die Gruppenrichtlinienverwaltung zu erreichen: Default Domain Controllers Policy – Computerkonfiguration – Richtlinien – Windows-Einstellungen – Sicherheitseinstellungen – Lokale Richtlinien – Zuweisen von Benutzerrechten – Lokales Anmelden zulassen.
  • Die Zugriffe auf die Verzeichnisse erfolgen mit dem jeweiligen über die SSID angegebenen Benutzer. Es müssen also ggf. für diese Benutzer entsprechende Windows-Zugriffsrechte für die Verzeichnisse zugeteilt werden.

Haben Sie Fragen? Melden Sie sich bei uns!