[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Jessie: OpenSSH internal-sftp Subsystem



Hallo,

danke für die Antworten:

On 08.10.2015 15:54, Matthias Böttcher wrote:
Hallo Harald und Olaf,

Am 8. Oktober 2015 um 13:52 schrieb Harald Weidner <hweidner-lists@gmx.net>:
Hallo,

wir betreiben verschiedene Webservices, bei denen Kunden per SFTP
Uploads  machen können, und zwar über das "internal-sftp" Subsystem
von OpenSSH. Dies funktioniert auch prinzipiell, allerdings habe ich
unter Jessie das Problem der Informationspreisgabe des konkreten
Homedirs, wenn man sich probiert per _SSH_ einzuloggen, und der
Account eigentlich nur als SFTP-only Account vorgesehen ist.
user@linux:~$ ssh  foo@172.16.1.128
Could not chdir to home directory /home/foo: No such file or
directory                       ##  <-   Um diese Zeile geht es mir
This service allows sftp connections only.
Ich sehe diese Zeile nur, wenn ich mich per ssh mit einem
sftp-Benutzer erfolgreich authentifiziert habe.
Bitte prüfe das noch mal in deinem Setup.

Genau dass ist hier auch der Fall: Der User soll eigentlich nur SFTP-Zugriff haben, probiere ich dennoch mich per SSH zu verbinden _und_ es ist ein gültiger Key hinterlegt, kommt es zu der o.g. Meldung.

Ich möchte auch ausdrücklich das "internal-sftp" benutzen, und keine "echte" Chroot Umgebungung inklusive Kopieren von "/dev/" Dateien etc. Die man sshd_config sagt dazu:

----
The ChrootDirectory must contain the necessary files and directories to support the user's session. For an interactive session this requires at least a shell, typically sh(1), and basic /dev nodes [...] For file transfer sessions using “sftp”, no additional configuration of the environment is necessary if the in-process sftp server is used, [...] .
---


In meinem funktionierenden ssh+sftp-Setup sind ChrootDirectory und
$HOME gleich gesetzt mit
    ChrootDirectory %h
so wie bei Olaf.

Um die Meldung wegzubekommen, kannst du also entweder das gewünschte
Verzeichnis anlegen, also /home/foo/home/foo.
Das ist nicht notwendig, wenn ChrootDirectory root gehört (siehe unten).

Ich erstelle für solche User immer ein Verzeichnis /home/foo/data
und trage dann /data als Homeverzeichnis in die /etc/passwd ein.
/home/foo ist die Chroot-Umgebung und gehört root:root,
/home/foo/data ist das Arbeitsverzeichnis, in dem der User volle
Rechte hat.
Das ist wichtig und ist in meinem Setup auch so umgesetzt:
Aller Verzeichnisse im Pfad zum ChrootDirectory müssen root gehören
und group und other dürfen keine Schreibrechte darauf haben.
siehe: man sshd_config (Anschnitt ChrootDirectory)
Das habe ich grundsätzlich auch so umgesetzt, und bekomme auch keine "bad ownership" Meldungen. SFTP funktioniert auch wie vorgesehen. Nur irritiert mich die Meldung bei Zugriff per SSH, da ich sie bei identischem Setup unter Wheezy nicht auftrat.

Aktuell sehen meine Verzeichnis Rechte wie folgt aus (die authorized_keys gehört in dem fall "foo", damit er selbst Keys hochladen kann, aber auch wenn ich die Dateien "root" übertrage und die Rechte verschärfe, bleibt es bei der Meldung:
----
root@server:~# find /home/ -ls
  1684    4 drwxr-xr-x   3 root     root         4096 Okt  8 16:22 /home/
1056 4 drwxr-xr-x 4 root root 4096 Okt 8 17:07 /home/foo 1065 4 drwxrwxr-x 2 foo foo 4096 Okt 8 16:31 /home/foo/.ssh 10997 4 -rw-rw-r-- 1 foo foo 803 Okt 8 16:31 /home/foo/.ssh/authorized_keys 11036 4 drwxrwx--- 2 foo foo 4096 Okt 8 16:26 /home/foo/upload
-----


Vielleicht bin ich ja zu kleinlich... weil die Meldung ja nur bei Usern auftritt, die ohnehin einen gültigen SSH-Key für diesen Account hinterlegt haben, und ansonsten alles wie gewünscht funktioniert. Aber aus meiner Sicht bleibt es aber "Informationspreisgabe", wenn ich als Außenstehender für einen "chrooted" Service (hier in Anführungszeichen weil Subsystem internal-sftp) das konkrete Verzeichnis auf der Festplatte erfahre.

Und "früher (unter Wheezy) war alles besser" ;-)



Viele Grüße
Olaf


Reply to: