questions regarding nsswitch and the internal-sftp server and ChrootDirectory options
Ben H
bhendin at gmail.com
Thu Aug 14 11:20:48 EST 2014
What is the intended behavior of the internal-sftp server when looking
to resolve identity information for user via the nsswitch configured
mechanisms?
I am seeing different behavior between two packaged versions and am
looking to understand what should be expected.
Scenario:
Utilizing a developed directory services plugin (dsplug), "ls" access
on the sftp session fails with the following on a RHEL 6.5 machine
with OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013:
CONSOLE OUTPUT:
---------------
sftp localjoe at localhost
Connecting to localhost...
Password:
sftp> ls
Connection closed
LOG OUTPUT:
-----------
tail /var/log/secure
Aug 13 19:27:17 centos65-01 sshd[6203]: Accepted
keyboard-interactive/pam for localjoe from ::1 port 38958 ssh2
Aug 13 19:27:17 centos65-01 sshd[6203]: pam_unix(sshd:session):
session opened for user localjoe by (uid=0)
Aug 13 19:27:17 centos65-01 sshd[6208]: subsystem request for sftp
Aug 13 19:27:19 centos65-01 sshd[6209]: error: select: Bad file descriptor
Aug 13 19:27:19 centos65-01 sshd[6208]: Received disconnect from ::1:
11: disconnected by user
Aug 13 19:27:19 centos65-01 sshd[6203]: pam_unix(sshd:session):
session closed for user localjoe
STRACE OUTPUT:
-------------
lstat("/sftptest", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/etc/localtime", 0x7fff2c118340) = -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)
close(4) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR) = 0
connect(4, {sa_family=AF_FILE, path="/opt/dsplug/sockets/.auth"}, 110)
= -1 ENOENT (No such file or directory)
close(4) = 0
open("/etc/group", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
select(5, [3], [4], NULL, NULL) = -1 EBADF (Bad file descriptor)
I am able to get around these issues with the following in nsswitch.conf:
passwd: files [UNAVAIL=return] nis dsplug
shadow: files nis
group: files [UNAVAIL=return] nis dsplug
This however has the negative effect of not resolving any UID/GID
information within the sftp session.
On a Kubentu 13.11 machine with OpenSSH_6.2p2 Ubuntu-6ubuntu0.1,
OpenSSL 1.0.1e 11 Feb 2013, this issue does not occur in a default
configuration.
An strace on that system shows that no calls past passwd/group files
are made and no attempt seems to be done to resolve any naming
information (including local passwd/group)
Should internal-sftp make any attempt past local passwd/group files?
It appears at least in the RHEL testing if only "files nis" is
configured that NIS names will be properly resolved... ?
thank you
More information about the openssh-unix-dev
mailing list