[Date Prev][Date Next] [Chronological] [Thread] [Top]

More info: TLSVerifyClient: Basic setup works, but SSHD and su fail (SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server)



Hi again,

when I make

   sudo /etc/init.d/ssh restart

after reboot, the network users can login, even when
the tls_cert and tls_key options in /etc/ldap.conf
have been disabled. After rebooting the machine,
the login fails and I have to login as local user
to restart the sshd.


  <some user>@<some host>:~> ssh <network_user>@<client>
  <network_user>@<client>'s password: 
  Permission denied, please try again.
  <network_user>@<client>'s password: 

  <some user>@<some host>:~> ssh <local_user>@<client>
  <local_user>@<client>'s password: 
  Last login: Sat Aug 30 10:25:56 2008 from <some host>
  <local_user>@<client>:~$ sudo /etc/init.d/ssh restart
  [sudo] password for <local user>: 
   * Restarting OpenBSD Secure Shell server sshd                           [ OK ] 
  <local_user>@<client>:~$ logout
  <some user>@<some host>:~> ssh <network_user>@<client>
  <network_user>@<client>'s password: 
  Last login: Sat Aug 30 10:23:40 2008 from <some host>
  <network_user>@<client>:~$ 

I'm very confused now!

Best regards,

Hauke

----- UrsprÃngliche Mail -----
Von: "Hauke Coltzau" <hauke.coltzau@FernUni-Hagen.de>
An: "Buchan Milne" <bgmilne@staff.telkomsa.net>
CC: openldap-technical@openldap.org
Gesendet: Freitag, 29. August 2008 21:33:08 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien
Betreff: 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

--