Authenticating users from proprietary user databases

[Christian Iversen]

On 2009-10-05 20:27, Yaniv Aknin wrote:
> Hi,
>
> I work for a company which develops a rather complicated Linux-based
> grid-technology appliance. The appliance is made of several Linux hosts,
> exposing its functionality over a proprietary CLI-like protocol. This
> protocol currently works by running a proprietary client executable on a
> host, sending the command via TCP/IP to one of the appliance's hosts and
> receiving the response. The client handles authentication, compression, etc.
> In addition, it is possible to access the various hosts of the clustered
> appliance as a regular Linux host using plain SSH for technician maintenance
> (not exposed to customers).
>
> I'm a big proponent of exposing our CLI over SSH as well and doing away with
> the proprietary "cli executable". Already the CLI executable can run inside
> the appliance itself, and I'd very much like it to be possible to run a
> single CLI command by running:
> $ ssh user at appliance command parameter=value
> ...and also to make it possible to run a readline based appliance-CLI
> interactive "shell" (we already have something like that) by running:
> $ ssh user at appliance
>
> We can easily separate (at least, at the transport layer) between the
> "maintenance" SSH shell and the "CLI" SSH shell by running two sshd
> instances and binding them to different ports (or addresses).

Does this mean that you want every user to be able to log on in either 
"CLI" or "maintenance" mode? Otherwise, just set the shell of the 
specific users to the right shell.

> The issue I'm not sure how to tackle is how to make SSH 'natively'
> authenticate the appliance's built-in users. Our appliance has its own user
> directory with credentials, unrelated to the passwd/shadow directory of
> nsswitch. The 'obvious' solution is to write an nsswitch module which will
> fake all users from the appliance's proprietary directory as passwd:shadow
> entries (we store the passwords in a way that is shadow compatible), and
> give all users a uniform passwd entry with only the username/shadow hash
> changing. This entry will have a fixed UID, GID, shell and homedir, and this
> fixed homedir will contain an authorized_keys file that will dynamically
> contain keys as set for our appliance's users (I'll add the CLI command
> "user_add_ssh_key" or something).
>
> While the above solution is, like I said, obvious, it has a very severe
> drawback I'm not sure how to tackle, and that's the fact that nsswitch
> modules are system global. I don't want our hosts' Linux users (root,
> nobody, daemon, etc) to collide with the appliance's users and vice versa,
> and I'd definitely not want to jeopardize the stability of core Linux
> services in any way by adding something as complex as looking up our
> clustered database for users from within all processes in the system.
>
> I'm not sure how to further handle this. Should I patch OpenSSH itself (oh
> god, please, no...)? Should I use some dynamic LD_PRELOAD concoction to
> 'rewrite' nsswitch.conf only for this sshd instance? Should I give up on
> OpenSSH entirely and use an SSH implementation which is less focused on
> letting system-users run shell-commands (like twisted.conch, or maybe
> others)? All these options are... well, doable, but all seem like a lot of
> (fragile) work. I'd appreciate comments and ideas.

I have worked with authentication solutions before (specifically with 
NSS), and as far as I can see, you have a few options. I'll let you 
decide which one suit your needs better, if any:

1a) Make an NSS plugin

     (as you suggested)

1b) Make an NSS plugin with virtual usernames

     As 1a, but prefix all usernames with a common prefix, such as "cli_"

     That way, the names cannot clash.

2) Actually export CLI users into system users in passwd and shadow

    Doesn't seem very nice, but it could work

3) Use libnss-extrausers

    This existing plugin allows you to have an entirely seperate set of 
passwd/group/shadow files, that are not related to the usual ones in 
/etc. This way, you can safely make an export of all your users into the 
files in /var/lib/extrausers, without risking anything. Worst case, only 
your CLI users are affected by any problems.

4) Use a common database for all users

    If you can export your current users (and change your existing 
tools) to use something like PostgreSQL or LDAP for storing users, you'd 
be able to use existing NSS plugins to connect to them.

Out of these options, I'd recommend that you look at number 3, since 
it's so dead simple to use, while still (I believe) solving your problem.

-- 
Med venlig hilsen
Christian Iversen