Authenticating users from proprietary user databases

[Yaniv Aknin]

Thank you very much for your prompt and interesting replies.

To make sure I'm perfectly clear, I'd like complete separation between the
"CLI" users and "maintenance" users. Not every CLI user is a maintenance
user, nor is every maintenance user a CLI user. Maintenance users are
regular Linux users (/etc/passwd) and CLI users are defined by the users of
the appliance, who should be 100% abstracted from the fact this is actually
a bunch of Linux boxes. I'd like the separation to be complete enough that
it would be possible to create a user in the CLI called, say, "root", and
have that user be completely unrelated to Linuxes /etc/passwd UID-0 user
root we all know.

Christian, from your suggestions, I'm indeed most interested in (3) and
maybe (1b), but the issue which still remains is how to make the NSS plugin
I'll use specific to the OpenSSH process (and its only child, the CLI
executable), so that not all processes in my system would be affected by
this change. From my cursory look at nss-extrausers, I can't see a way to
limit it to a specific process, but please enlighten me if I'm wrong.

I'm willing to go with "override getpwnam()" method suggested by Darren
(either statically as Darren stated or indeed with LD_PRELOAD), but I'd be
happy to hear another suggestion, if you have any.

Thanks again,
 - Yaniv

On Mon, Oct 5, 2009 at 10:31 PM, Christian Iversen
<chrivers at iversen-net.dk>wrote:

> 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
>