New Website allow LDAP integration and enable ssh login with LDAP

[robe]

As noted here:

​https://lists.osgeo.org/pipermail/sac/2017-October/008719.html

We have new website development server setup. Once Alex and Venkat work out contract with GetInteractive to move over the site to our new server, we'll want to start implementing the LDAP integration.

In order to do that in test environment, strk said it's doable but just need to whitelist the IP.

The IP / name of new server is as follows:

IPv4 address..: 141.138.205.23 
IPv6 address..: 2a02:348:84:cd17::1 
Hostname......: osgeo.public.cloudvps.com

[strk]

I found that IP already witelisted. Took the chance to put /etc/init.d/ipfilter under a local (/etc/init.d/.git) git repository

[martin]

Activated, meet ldaps://ldap.osgeo.org/, BaseDN is "dc=osgeo,dc=org", people are in "ou=People,dc=osgeo,dc=org", groups in "ou=Group,dc=osgeo,dc=org"

[robe]

martin, strk thanks. Martin did you touch the new server at all wasn't clear from your note above.

If not I'll try to do the next steps of configuring server for LDAP authenticated ssh login.

[robe]

I'm not having much luck with getting SSH LDAP access working with the new server. Connecting to our ldap server works though since I can do:

ldapsearch -x uid=robe

and it gives me my account details.

The passwords for new server are in secure access/osgeo.public.cloudvps.com

The steps I did so far detailed here:

​https://wiki.osgeo.org/wiki/SAC:betawebsite

We have no instructions on how to configure a brand new server. All our instructions assume you are starting with the OSGeo base VM.

[robe]

Okay I got SSH working thru LDAP now by reverse engineering the osgeo6 stuff and updated the link above.

I did have to create local users though otherwise get invalid credentials. Maybe that's always done.

Anyway I'll close this ticket out once someone checks my work.

I've added martin, wildintellect, strk to sudo group

[martin]

Oh, I'm too late .... ;-)

Did you actually use libpam/libnss-ldap*d* ? At least that would be the recommended way in order to deal with GnuTLS setuid-habits. If you want me to do so, I'd offer to check/revise the current setup tomorrow.

[robe]

martin that would be great to look at it. I had installed libnss-ldap after I installed the other ldap stuff and it threatened to remove a whole bunch of things which I said no to. So not quite sure if it's in use or not. Anyway if you want to check the setup tomorrow, that would be swell.

Anyway look at the link ​https://wiki.osgeo.org/wiki/SAC:betawebsite most of the files after install of stuff were teh same as osgeo6 except for ldap

/etc/nslcd.conf

and /etc/ldap/ldap.conf

which I emulated what I saw on osgeo6 server.

The one line that confused me on the ldap.conf of osgeo6 was the line

in /etc/ldap/ldap.conf

pam_groupdn cn=telascience,ou=Shell,dc=osgeo,dc=org

I wasn't sure why we have anything referencing telascience anymore.

[strk]

I don't think we ever needed to create local users for SSH login via LDAP to work.

Can you document the procudure required for enabling the SSH login on the wiki ? Then we can tweak once the need to create local user is sorted out.

[martin]

# Avoid error messages upon login

root@osgeo:~# aptitude install locales-all

# Have the preferred LDAP subsystem

root@osgeo:~# aptitude install libpam-ldapd libnss-ldapd

# Purge deprecated configs

root@osgeo:~# dpkg -l | grep \^rc | awk '{print $2}' | cut -f 1 -d \: | xargs dpkg --purge

# Purge local user

root@osgeo:~# grep -v \^martin /etc/passwd > Hallo && cat Hallo > /etc/passwd
root@osgeo:~# grep -v \^martin /etc/shadow > Hallo && cat Hallo > /etc/shadow
root@osgeo:~# rm -vf Hallo

# Purge cache and reload LDAP stuff

root@osgeo:~# /etc/init.d/nscd stop; rm -vf /var/cache/nscd/*; /etc/init.d/nscd  start
root@osgeo:~# /etc/init.d/nslcd  restart

# Voila

root@osgeo:~# getent passwd martin
martin:x:10026:100:Martin Spott:/home/martin:/bin/tcsh

# Have a homedir and proper login shell

root@osgeo:~# cp -a /etc/skel /home/martin
root@osgeo:~# chown -R martin:100 /home/martin
root@osgeo:~# aptitude install tcsh

# Reduce authentication error log

root@osgeo:~# aptitude install fail2ban

# Now test

foehn: 17:06:08 ~> ssh osgeo.public.cloudvps.com
martin@osgeo.public.cloudvps.com's password: 
[...]
osgeo:~>

# Success

I got a fresh copy of "nslcd.conf" and the certificate file from Osgeo6, but that's just cosmetic style

BTW, using "*-ldapd libraries and nslcd makes /etc/ldap/ldap.conf obsolete

[strk]

Thanks for the report ! (worth adding in a wiki page)

About this:

root@osgeo:~# getent passwd martin
martin:x:10026:100:Martin Spott:/home/martin:/bin/tcsh

Isn't it possible to get a group for each user, as it is common since a long time in standard debian systems ?

[martin]

This is my watered-down reponse ;-)

Of course it's technically possible to have a distinct user group for every user, but what's the benefit to justify the maintenance overhead ? Just because some Linux distros do it doesn't automatically imply that it makes sense for serious environments.

As you may realize, I'm not a fan of it :-)

[strk]

The benefit is we can set umask to 0002 and thus use set-gid directories more. Just a way to reduce access to just the needed one, rather than giving sudo to everyone :)

That said, I'm probably too much of a control freak.

[martin]

To me it's not a matter of being a control freak or not, I *do* care about the health of the systems I maintain!

If you can elaborate a use case in OSGeo land which can't be solved without distinct groups for every single user, I'll (probably ;-)) give up my resistance.

Instead, from my perspective the risk to OSGeo's server infrastructure isn't a technical one. Better control over directory permissions *is* technically possible in many cases, but in some people simply prefer granting "sudo" permissions because it's less burdensome and you're not going to solve that one by creating thousands of individual user groups.

[strk]

I agree the problem is more with culture than technical limit.

The umask idea only serves the purpose of reducing the effort required to properly set group permissions when creating files in a "group" area. When such directories have the set-gid flag set files you create in them are automatically assigned to the directory group, and with proper umask are also writeable by them. Example use ? ~/root/access/<subsystem> on secure host could be only granted access to those who need to take care of <subsystem>.

Anyway, forget about it, not worth the effort, probably

[robe]

martin can you update ​https://wiki.osgeo.org/wiki/SAC:betawebsite with the changes you made to the server.

I used apt-get for example and your above usese aptitude. So not sure if you switched to using aptitude or continued with apt-get.

Also regarding your irc. I didn't install rpc:bind or not intentionally so if you see it guess you can remove it.

I'm going to move the rest of this LDAP discussion to another ticket.

[robe]

I added martin's step to the above link so I'm closing this out.