blog'o thnet

Why set the authorized_keys file to a local pathname on large UNIX environments, especially when NFS shares are used for home directories? Because this can address security problems.

First, you must remember that this special SSH file stores the public key of a remote account, letting the owner to be able to log-in using asymmetric keys along with the corresponding passphrase instead of the more classical challenge with appropriate password mechanism. (This eventually enable for non-interactive login through the use of an SSH agent, latter.)

The default path for the authorized_keys file is in a subdirectory of the home directory. This means that when the home of a UNIX account is hosted on a NFS share, all servers available in the same domain as the NFS resource will have access to the very same authorized_keys file, thus opening a security flaw. This is a security concern since by allowing one account on one server, you open this account to all servers in the same domain.

So, the first benefit to store the authorized_keys file in a local name space on each server is to authorize one--and only one--access to a given machine. The direct drawback is that there will be as many authorized_keys file as the number of servers in a domain (if a SSH access is needed on all servers). A side effect is that the path, mode and owner of the directory which will host the authorized_keys file may be better managed and hardened than before (even if SSH already check those things for sane defaults). It is particularly of interest when managing thousands of servers in heterogeneous UNIX environment, when Solaris, AIX, Linux and HP-UX doesn't have the same ownership same system paths (such as /var, for example).

As it is repeatedly discussed at work these days, I think it may worth mentioning there exists official locations to install bundled and unbundled packages, and well defined paths with a recommended purpose for most major players in UNIX and UNIX-like platforms such as Solaris, GNU/Linux and FreeBSD for example.

For Solaris (and OpenSolaris derived distributions), you can consult the Recommended Installation Locations for Solaris-compatible Software Components document from the Architecture Process and Tools community, along with the filesystem(5) manual page online, or on an installed system.

For a GNU/Linux environment, you can read both the Linux Standard Base and the Filesystem Hierarchy Standard recommendations.

Although the BSD are not so well-known as GNU/Linux, there are some very good and alive projects. More, the documentation available for each distributions are well written, and frequently updated. For these systems, and most notably FreeBSD and HP-UX systems, you can read the hier(7) manual page online, or on a live system.

As a side note, it is interesting to note that Ian Murdock (founder of the famous Debian GNU/Linux distribution, and just joining Sun to head up operating system platform strategy) is also the chair of the Linux Standard Base—while Sun is a member of the Linux Foundation (which host the LSB project). Maybe can we expect more standardization between these two major players in the future?

As we hear more and more things about server or data center virtualization nowadays, i found those those two articles to be very clear and interesting in explaining what is really involve behind this general term (virtualization).

The first one came from the developerWorks, whereas the second one is hosted on InformationWeek. Worth reading, really.

Since a friend of mine told me recently to give him my very favorite links about zouk music on the Net, here it is. In fact, i currently post this one listening a web radio station using RealPlayer plugin running on top of OpenSolaris on my personal Sun Ultra 20 Workstation ;)

1. ZoukStation.com [fr]
2. Zouker.com [fr]
3. ZoukOnWeb [fr]
4. Sol2Zouk [fr]

Don't hesitate to email me if you have some good web sites too; i promise you to update this entry, if any!

This little real-life example will be based on changing the user's login shell for a given account.

• grills represents the LDAP server (master)

Verify that the user exists in the directory server:

# ldaplist passwd jpeg
dn: uid=jpeg,ou=people,dc=thilelli,dc=net

Get detailed parameters for this account:

# ldaplist -l passwd jpeg
dn: uid=jpeg,ou=people,dc=thilelli,dc=net
        cn: jpeg
        uidNumber: 1000
        gecos: Gabel, Julien
        homeDirectory: /u/jpeg
        gidNumber: 1000
        objectClass: posixAccount
        objectClass: shadowAccount
        objectClass: account
        objectClass: top
        uid: ut0tar
        userPassword: XXXXXXXX
        shadowLastChange: 6445
        shadowFlag: 0
        loginShell: /usr/local/bin/bash

Create the desired modifications using a ldif LDAP file:

# ldaplist -l passwd jpeg > ldapmodifiy.jpeg.ldif
/* Edit and save the ldif file. */
#
# cat ldapmodifiy.jpeg.ldif
dn: uid=jpeg,ou=people,dc=thilelli,dc=net
changetype: modify
replace: loginShell
loginShell: /usr/local/bin/ksh

Inject this modification(s) into the LDAP server:

# ldapmodify -h grills -D "cn=Directory Manager" -f ldapmodifiy.jpeg.ldif
Enter bind password: 
modifying entry uid=jpeg,ou=people,dc=thilelli,dc=net

Verify that the changes are done as expected:

# ldaplist -l passwd jpeg
dn: uid=jpeg,ou=people,dc=thilelli,dc=net
        cn: jpeg
        uidNumber: 1000
        gecos: Gabel, Julien
        homeDirectory: /u/jpeg
        gidNumber: 1000
        objectClass: posixAccount
        objectClass: shadowAccount
        objectClass: account
        objectClass: top
        uid: ut0tar
        userPassword: XXXXXXXX
        shadowLastChange: 6445
        shadowFlag: 0
        loginShell: /usr/local/bin/ksh

The example shown below use the ldaplist(1) and ldapmodify(1) commands line, which use and options may vary between OS versions and/or family. Be warned.