openssh unix dev - Mar 2014 - internal-sftp stuck on 'ls' with chrootdirectory

Hi all,

I am using Match directive and internal-sftp to chroot sftp users into their
directory. Connection and login works. I can change directories and put/get
files. Also logging of the internal sftp-process works (created a /dev/log
socket inside the chroot). As soon as I use the 'ls' command, nothing
happens and the the process gets stuck. Listing files does work as soon as I
remove the chrootdirectory directive.

Configuration details:
>From the end of the /etc/ssh/sshd_config:
	Subsystem sftp internal-sftp
	Match User p16012
      	  	ChrootDirectory /srv/www/xxxxx.de
        		ForceCommand internal-sftp -l VERBOSE -f LOCAL6


I have created an additional socket for the rsyslog deamon inside the chroot
directory and logging works fine:
Mar 17 16:42:24 nina internal-sftp[6749]: session opened for local user
p16012 from [84.xx.xxx.66]
Mar 17 16:42:24 nina internal-sftp[6749]: received client version 3
Mar 17 16:42:24 nina internal-sftp[6749]: realpath "."
Mar 17 16:42:27 nina internal-sftp[6749]: opendir "/"
>From the auth.log I get:
Mar 17 16:42:24 nina sshd[6745]: Accepted password for p16012 from
84.xx.xxx.60 port 50295 ssh2
Mar 17 16:42:24 nina sshd[6745]: pam_unix(sshd:session): session opened for
user p16012 by (uid=0)
Mar 17 16:42:24 nina sshd[6748]: subsystem request for sftp by user p16012

I also did strace the internal-sftp process:
root at nina:/srv/www/xxxxx.de# strace -s 50 -a 200 -p 6846
Process 6846 attached - interrupt to quit
select(2, [0], [], NULL, NULL)
= 1 (in [0])
read(0, "\0\0\0\20\v\0\0\177t\0\0\0\7/htdocs", 16384)
= 20
time([1395071933])
= 1395071933
socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0)
= 3
connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110)
= 0
sendto(3, "<182>Mar 17 16:58:53 internal-sftp[6846]: opendir
"..., 59,
MSG_NOSIGNAL, NULL, 0)                   = 59
close(3)
= 0
open("/htdocs", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC)
= 3
select(2, [0], [1], NULL, NULL)
= 1 (out [1])
write(1, "\0\0\0\rf\0\0\177t\0\0\0\4\0\0\0\0", 17)
= 17
select(2, [0], [], NULL, NULL)
= 1 (in [0])
read(0, "\0\0\0\r\f\0\0\177u\0\0\0\4\0\0\0\0", 16384)
= 17
getdents(3, /* 5 entries */, 32768)
= 144
lstat("/htdocs/.", {st_mode=S_IFDIR|S_ISUID|0750, st_size=52, ...})
= 0
stat("/etc/localtime", 0x7ffffaef12c0)
= -1 ENOENT (No such file or directory)
open("/etc/localtime", O_RDONLY)
= -1 ENOENT (No such file or directory)
open("/etc/passwd", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
geteuid()
= 6012
getegid()
= 6012
open("/etc/group", O_RDONLY|O_CLOEXEC)
= -1 ENOENT (No such file or directory)
futex(0x7f0c0d3b61e0, FUTEX_WAIT_PRIVATE, 2, NULL

The process stays there until I kill it on the server. I can see from the
trace that the process tries to access /etc/localtime, passwd and group. Of
course those files are not present in my chroot environment and my
understanding is, that using internal-sftp does not require those.

I have found
http://unix.stackexchange.com/questions/32882/sftp-server-on-rhel6-disconnec
ts-on-ls, which is slightly comparable. I do not get disconnected and I am
on Debian, but symptoms are the same. I am using PAM with libnss-mysql.

Any help is welcome.

Thanks
Brian Rosenberger

On Mon, 17 Mar 2014, Brian Rosenberger wrote:
> Hi all,
> 
> I am using Match directive and internal-sftp to chroot sftp users into
their
> directory. Connection and login works. I can change directories and put/get
> files. Also logging of the internal sftp-process works (created a /dev/log
> socket inside the chroot). As soon as I use the 'ls' command,
nothing
> happens and the the process gets stuck. Listing files does work as soon as
I
> remove the chrootdirectory directive.
...
> I am using PAM with libnss-mysql.
This is likely the problem - the chrooted process is probably trying to
connect to your MySQL server and failing. You could either arrange for
MySQL to listen at the path it is expecting inside the chroot or see if
you can trick nss-mysql into giving up by creating a stale socket at
the path it is expecting.

The first approach would give you correct usernames for 'ls -l' at the
cost of potentially exposing sensitive data inside the chroot. The
latter loses usernames but keeps the chroot clean.

(all assuming this is indeed the problem)

-d