ls hangs in internal-sftp for LDAP users + numeric uid/gid instead of names

mh at ow2.org mh at ow2.org
Thu May 18 20:17:35 AEST 2017


Le 12/05/2017 à 14:03, Alexander Wuerstlein a écrit :
> On 2017-05-12T13:49, mh at ow2.org <mh at ow2.org> wrote:
>> Le 12/05/2017 à 12:47, Alexander Wuerstlein a écrit :
>>> On 2017-05-12T12:07, mh at ow2.org <mh at ow2.org> wrote:
>>>> I'm using 7.2p2-4ubuntu2.1
>>>>
>>>> I have the same exact problem as described in the first comment in
>>>> https://bugzilla.mindrot.org/show_bug.cgi?id=1573
>>>>
>>>> Initially, my ldap server hostname and IP is only in /etc/hosts, not in
>>>> the configured resolver. I can't use the real IP as a workaround in
>>>> ldap.conf because of the TLS configuration which cares about the hostname.
>>>>
>>>> At the time I add the host name and IP in the resolver, the issue goes away.
>>>>
>>>> So, I'm a bit worried to be forced to declare a record in my DNS to
>>>> enable SFTP listing ? There should be another way isn't ?
>>>>
>>>> I also tried to copy /etc/hosts to etc/hosts in the folder specified by
>>>> ChrootDirectory directive with no more success.
>>>>
>>>> Notice : it happens only for ldap users, not local users
>>>
>>> There should be a /etc/nsswitch.conf in your chroot where you can
>>> configure where users and hostnames should be looked up. E.g. to prevent
>>> LDAP lookups altogether you could configure the respective two lines to
>>> read:
>>> passwd:		files
>>> group:		files
>>> i.e. drop the 'ldap' option there. To check why /etc/hosts isn't being
>>> used you can look if hosts: has 'files dns' or just 'dns' altogether
>>> behind it.
>>>
>>> But in general I would recommend putting all your hostnames into DNS
>>> properly, in my experience this avoids all kinds of headaches with all
>>> kinds of software. And leave /etc/hosts as empty as possible, because
>>> that always grows inconsistent over time.
>>>
>>>
>>
>> Thanks Alexander,
>>
>> I'll try the nsswitch.conf suggestion. Until then I've noticed the
>> following : while the ldap hostname is into the DNS, if I also put a the
>> corresponding line to etc/hosts in the chroot the hang happens again. So
>> the hosts file in the chroot is red somehow.
> 
> It shouldn't hang in that case, thats strange. However, the order of the
> options in nsswitch.conf determines which way to look up the hostname is
> tried first, second, ... etc. One thing that might be a problem (but I'm
> guessing, there might be a lot more going on[0]) would be whether you have
> just the hostname or the FQDN in your ldap.conf and /etc/hosts. And if
> its not the FQDN in some place, then what your search path in
> /etc/resolv.conf and the value of your dnsdomainname might be. 


I currently have in nsswitch.conf, in the etc folder inside the sftp's
chroot (/srv/ftpchroot/etc) :

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap
gshadow:        files

hosts:          files dns


Since I've update my DNS and switched to libnss-ldapd I can't reproduce
the hang so I'm unsure what was the cause...

However, I get uid/gid numbers instead of names within sftp session (ls
-l) ? I don't know if it's new but I would definitively prefer names...

> 
>> But if it reads the hosts file propertly, what is the problem then ?
> 
> I'm not sure. Maybe try determining if its a ssh/sftp problem first: In
> that chroot, does 'getent passwd' hang? Does it contain only local users
> or ldap users as well? Does 'getent hosts $ldaphostname' hang? If yes,
> its a problem with the libc name services that are behind getent and
> stuff, so you would have to fix the config (in nsswitch.conf and all the
> related things referenced from there). strace-ing the aforementioned
> getent calls might help narrowing things further down.

I'll try to determine this if needed if I bump into the issue again.


Q: How do you mean to run getent in the sftp chroot ? you mean from the
shell ? I would need to copy a bunch of binary/lib files to achieve that
I guess.

(I'm not even sure that the files I put in /srv/ftpchroot/etc are read
in some way)

Regards,


More information about the openssh-unix-dev mailing list