PAM-Modules
	A Collection of Modules for PAM	Sergey Poznyakoff

• Main
• Downloads
• Documentation

7.2 Example of pam_ldaphome configuration

This example assumes you are using GNU/Linux. The aim of this configuration is to allow remote access via sshd to users present only in the LDAP database, using ssh shared-key authentication. The exact way of achieving this depends on the version of opennsh daemon in use. The openssh version 6.2p1 introduced a possibility to obtain public keys by invoking an external command, so there are two main usage cases, as described in the subsections that follow.

7.2.1 Openssh versions prior to 6.2p1

The user public keys are kept in ‘grayPublicKey’ attribute of his LDAP entry. When a user logs in for the first time, his home directory does not exist yet and consequently sshd is not able to verify his key. Therefore it falls back to the interactive authentication (it is supposed, of course, that ‘UsePAM’ is set to ‘yes’ in the sshd configuration file). The authentication stage is supposed to create user home directory, populate his .ssh/authorized_keys with his public keys and present user with a descriptive text prompting him to cancel his current authentication attempt and retry it again. The corresponding pam.conf section looks as follows:

pam.conf

sshd auth [success=ok try_again=1 default=die] \
    pam_ldaphome.so 
sshd auth [success=done ignore=ignore default=die] \
    pam_unix.so
sshd auth [default=die]  pam_echo.so file=/etc/ldaphome.txt

The first line does most of the job. If pam_ldaphome.so succeeds in creating the user directory it will return ‘try_again’. This will cause skipping the next stack entry, so control will go to pam_echo.so, which will print a descriptive text from /etc/ldaphome.txt and exit indicating authentication failure.

The pam_ldaphome.so module returns ‘success’ if the user who is trying to log in should not be handled by it (e.g. because his UID is less than the ‘min-uid’ setting, etc.). In this case, authentication will be handled by pam_unix.so. This allows normal system accounts to function as usual. This is very important, because it will allow to access the machine even when the LDAP database is not available for some reason.

pam_ldaphome.conf

The pam_ldaphome.so configuration handles users with uids and gids greater than or equal to 1000 and pertaining to the group ‘remote’. User home dirs are populated from the /etc/skel directory.

min-uid 1000
min-gid 1000
allow-groups remote 
skel /etc/skel
base dc=gnu,dc=org,dc=ua
filter (&(objectClass=posixAccount)(uid=$user))
pubkey-attr grayPublicKey

Schema

The LDAP schema should include an attribute to keep the user public keys. The author uses the following schema:

# depends upon:
#    nis.schema

# Attribute Definitions
attributetype ( 1.3.6.1.4.1.9163.2.1.0 NAME 'grayPublicKey'
    DESC 'SSH public key'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
# Object Class Definitions
objectclass ( 1.3.6.1.4.1.9163.2.2.0 NAME 'grayAccount'
    DESC 'Abstraction of an employee account'
    SUP posixAccount AUXILIARY
    MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
    MAY ( userPassword $ loginShell $ gecos $ grayPublicKey ) )

/etc/nsswitch.conf

The ‘passwd’ and ‘group’ entries in /etc/nsswitch.conf file should be as follows:

passwd:         files ldap
group:          files ldap

7.2.2 Openssh versions 6.2p1 and newer

Versions of openssh starting from 6.2p1 are able to read public keys from the standard output of an external program. This can be used to improve the configuration described in the previous subsection so that the user is not required to cancel his session upon the very first connection. To that effect, pam-modules includes the utility ldappubkey, distributed in the examples subdirectory (see ldappubkey). Copy that utility to a convenient location (/usr/libexec would be a wise choice), and add the following two lines to your /etc/ssh/sshd_config file:

AuthorizedKeysCommand           /usr/libexec/ldappubkeys
AuthorizedKeysCommandUser       nobody

Two points should be observed. First, the argument to AuthorizedKeysCommand (and all its pathname components) must be owned by root and be writable only for the owner. Second, the use of AuthorizedKeysCommandUser statement is mandatory. Of course, you can chose any suitable user (not necessarily ‘nobody’).

After restarting sshd, it will invoke ldappubkeys on each log in attempt with the login name of the user as its argument. The utility will look up that user in the LDAP database, and if found, will print his piblic keys on its standard output. The sshd will then read the keys and try to authorize user against each of them. If none of the keys matches the private key supplied by the user, sshd will attempt public keys read from the user’s ~/.ssh/authorized_keys file (or another file, if overridden by the AuthorizedKeysFile statement in /etc/ssh/sshd_config).

Most of the configuration described in the previous subsection remains in effect. However, the authentication stack won’t be invoked if ldappubkeys functions successfully. The pam_ldaphome module must be invoked as a part of ‘session’ stack instead. The following example assumes it is invoked at the top of the stack:

sshd session [success=ignore try_again=ignore default=die] \
   pam_ldaphome.so