[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
AW: Re: TLSVerifyClient: Basic setup works, but SSHD and su fail (SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server)
Hi Buchan,
summary first: the su - <network_user> problem is solved thanks to
your question. ssh <network_user>@<client> works only under certain
circumstances (see below).
> > I want to use TLS-communication between my ldap server and
> > the clients.
>
> [...]
>
> > Next, I activated TLSVerifyClient on the server side
>
> Why ? You don't need this to address your single remaining problem,
> unless you haven't stated it in full.
Sorry, I did not point out that I want only valid users/services
to be able to get information from the ldap server at all. A valid service
or user shall be identified by a certificate that is signed by a valid CA
of mine. All other connection attempts shall be rejected. That is how I
understood the combination of TLS_REQCRT (to verify the server) and
TLSVerifyClient (to verify the client). Am I wrong here?
> Since I use the ldap server for network user authentication, I can (as
> local user) make a su - <network_user>, enter the password and get
> authenticated, but have a look at the shell:
>
> <local user>@<client>:~$ su - <network_user>
> Password: <network user password here>
> id: cannot find name for group ID <network_user group>
> I have no name!@<client>:~$
>
> Does 'strace -e open id' tell you anything interesting (specifically about
> the key/cert)?
Wow, one single question of yours gave me several hours of work and the solution
for my first problem. Thanks ;-)
I ensured that the requested files are readable by the user (they already
were, but I checked it again, even made a chmod -R 777 on the directory).
This was not the problem.
But after creating a new certificate for that network user with the CN set to
the users username (instead of the surname/name before), the problem with
su - <network_user> disappeared. Now I can su from a certified local user
to my network user.
<local user>@<client>:~$ su - <network user>
Password:
<network user>@<client>:~$
That's cool!
> > In /etc/ldap.conf (ubuntu 8.04 uses this as replacement for
> > lib(pam|nss)_ldap.conf),
>
> Actually, Ubuntu reverts back to the upstream location, lib(pam|nss)_ldap.conf
> is a Debian-ism.
Thanks for the info, did not know that.
> > I set the values for
> >
> > tls_cert /usr/lib/ssl/certs/<client>.ldap.cert.pem
> > tls_key /usr/lib/ssl/private/<client>.ldap.key.pem
>
> You didn't indicate any of the other /etc/ldap.conf settings, such as
> tls_cacertfile, tls_check_peer. Additionally, you don't specify if you are
> using nscd, or whether the logged in user (below) can read the tls_cert and
> tls_key files.
Since the verification of the server certificate works out fine, I only
provided the client-verification specific values. Here are the missing values:
base dc=...
uri ldaps://<fqdn of my server>/
ldap_version 3
bind_policy soft
pam_password md5
tls_check_peer yes
tls_cacertfile /usr/lib/ssl/cacerts/<serverca>.chain.pem
tls_cert /usr/lib/ssl/certs/<client>.ldap.cert.pem
tls_key /usr/lib/ssl/private/<client>.ldap.key.pem
nss_initgroups_ignoreusers backup,bin,daemon,dhcp,fetchmail,games,gnats,irc,klog,libuuid,list,lp,mail,man, \
messagebus,news,postfix,proxy,root,sshd,statd,sync,sys,syslog,uucp,www-data,zimbra
The nss_initgroups_ignoreusers entry is automatically created when
executing /etc/init.d/libnss-ldap restart or when booting the system.
I disabled the nscd caches for passwd and group before starting to deal
with TLS just to make sure that the ldap server is always contacted.
==== /etc/nscd.conf ====
...
enable-cache passwd no
...
enable-cache group no
...
== END /etc/nscd.conf ==
After tideous testing I found out something new:
I wanted to strace the sshd, too and therefore stopped the running
instance with /etc/init.d/ssh stop and started a new instance manually
<local user>@<client> sudo -s
root@<client># /usr/sbin/sshd -D
Doing so, the login via SSH works sout perfectly. I assumed that this is because
sshd would read the .ldaprc of <local user>, which has a valid cert/key entry (see above),
so I straced the above command. But:
root@<client>:/etc/init.d# strace -e open /usr/sbin/sshd -D 2>&1
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib/libwrap.so.0", O_RDONLY) = 3
open("/lib/libpam.so.0", O_RDONLY) = 3
open("/lib/libdl.so.2", O_RDONLY) = 3
open("/lib/libselinux.so.1", O_RDONLY) = 3
open("/usr/lib/libck-connector.so.0", O_RDONLY) = 3
open("/usr/lib/libdbus-1.so.3", O_RDONLY) = 3
open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3
open("/lib/libutil.so.1", O_RDONLY) = 3
open("/usr/lib/libz.so.1", O_RDONLY) = 3
open("/lib/libnsl.so.1", O_RDONLY) = 3
open("/lib/libcrypt.so.1", O_RDONLY) = 3
open("/lib/libresolv.so.2", O_RDONLY) = 3
open("/usr/lib/libgssapi_krb5.so.2", O_RDONLY) = 3
open("/usr/lib/libkrb5.so.3", O_RDONLY) = 3
open("/usr/lib/libk5crypto.so.3", O_RDONLY) = 3
open("/lib/libcom_err.so.2", O_RDONLY) = 3
open("/lib/libc.so.6", O_RDONLY) = 3
open("/usr/lib/libkrb5support.so.0", O_RDONLY) = 3
open("/lib/libkeyutils.so.1", O_RDONLY) = 3
open("/etc/selinux/config", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/proc/mounts", O_RDONLY) = 3
open("/dev/null", O_RDWR) = 3
open("/proc/14556/fd", O_RDONLY|O_NONBLOCK|O_DIRECTORY|0x80000) = 3
open("/etc/ssh/sshd_config", O_RDONLY) = 3
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
open("/etc/gai.conf", O_RDONLY) = 3
open("/etc/nsswitch.conf", O_RDONLY) = 3
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib/libnss_files.so.2", O_RDONLY) = 3
open("/etc/passwd", O_RDONLY|0x80000 /* O_??? */) = 3
open("/etc/ssh/ssh_host_rsa_key", O_RDONLY) = 3
open("/etc/ssh/blacklist.RSA-2048", O_RDONLY) = 3
open("/etc/ssh/ssh_host_dsa_key", O_RDONLY) = 3
open("/etc/ssh/blacklist.DSA-1024", O_RDONLY) = 3
open("/etc/localtime", O_RDONLY) = 4
open("/var/run/sshd.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
Now if I do ssh <network_user>@<client> from any machine in the net,
everything works out perfectly:
<some id>@<some host>:~> ssh <network_user>@<client>
<network_user>@<client>'s password:
Last login: Fri Aug 29 21:23:06 2008 from <fqdn of some host>
<network user>@<client>:~$
But not a single ldap or libnss/libpam config file is stat'ed or read
by the above sshd at all. The only thing that can be seen is that
after logging out, the above sshd command echos
--- SIGCHLD (Child exited) @ 0 (0) ---
and that's it.
When I kill the above sshd and do /etc/init.d/ssh start again, the login
still works out. But after restarting the sytem, the login fails as always.
As far as I can see, /etc/init.d/ssh starts sshd as root, obviously not
chrooted or something similar.
Do you have any idea, what this is all about?
Kind regards,
Hauke
--