Forums Neueste Beiträge
 

Jessie: OpenSSH internal-sftp Subsystem

08/10/2015 - 12:40 von Olaf Stölting | Report spam
Hallo Liste,

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.

Regulàrer SFTP Zugriff:
-
user@linux:~$ sftp foo@172.16.1.128
Connected to 172.16.1.128.
sftp> cd /
sftp> ls -la
drwxr-xr-x 3 0 0 4096 Sep 30 12:09 .
drwxr-xr-x 3 0 0 4096 Sep 30 12:09 ..
-rw-r-- 1 1000 1000 675 Sep 30 11:32 .profile
drwxr-x 2 1000 1000 4096 Oct 8 07:49 .ssh
-

Zugriff per SSH auf den selben Account:
-
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.
Connection to 172.16.1.128 closed.
-

Das ist in soweit unkritisch, als dass der Schlüssel des Benutzers in
".ssh/authorized_keys" eingetragen sein _muss_. Bots die "Klinken
drücken" bekommen die Zeile "Could not chdir to home directory
/home/foo" nicht zu sehen. Dennoch widerspricht das meinem Verstàndnis
von einem "Chroot" Service, dass das konkrete Verzeichnis auf der
Festplatte ausgegeben wird, wenn ich den Dienst nicht wie vorgesehen
anspreche.

Unter Wheezy trat die Meldung nicht auf, und hier erkenne ich auch dass
der "sftp-server" unter Jessie in ein extra Paket ausgelagert wurde.

Jessie:
-
ii openssh-client 1:6.7p1-5 amd64 secure shell
(SSH) client, for secure access to remote machines
ii openssh-server 1:6.7p1-5 amd64 secure shell
(SSH) server, for secure access from remote machines
ii openssh-sftp-server 1:6.7p1-5 amd64 secure shell
(SSH) sftp server module, for SFTP access from remote machines
-

Wheezy:
-
ii openssh-client 1:6.0p1-4+deb7u2 amd64 secure
shell (SSH) client, for secure access to remote machines
ii openssh-server 1:6.0p1-4+deb7u2 amd64 secure
shell (SSH) server, for secure access from remote machines
-

Relevanter Teil aus der sshd_config.
-
UsePAM no

Subsystem sftp internal-sftp -f AUTH -l INFO
Match Group sftp
ChrootDirectory %h
ForceCommand internal-sftp -u 0002
AllowTcpForwarding no

Ist das ein Bug, oder ein Feature, dass die Zeile "Could not chdir to
home directory /home/foo: No such file or directory" ausgegeben wird?

Mehr Informationen schicke ich gerne auf Anfrage.


Viele Grüße
Olaf
 

Lesen sie die antworten

#1 Harald Weidner
08/10/2015 - 14:00 | Warnen spam
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.

:~$ ssh
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.



Vermutlich hast du in der /etc/passwd beim User foo /home/foo als
Homeverzeichnis eingetragen.

Das Problem ist, dass der SSHD nach dem Login und NACH dem chroot()
auf /home/foo nochmal in das Homeverzeichnis wechseln möchte und es
das innerhalb der Chroot-Umgebung nicht gibt.

Um die Meldung wegzubekommen, kannst du also entweder das gewünschte
Verzeichnis anlegen, also /home/foo/home/foo. Oder du tràgst in der
/etc/passwd ein Homeverzeichnis ein, das es in der Chroot-Umgebung
gibt, z.B. /.

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.

Gruß, Harald

Ähnliche fragen