Is there a preferred way of managing ssh keys across multiple servers, for multiple users?  Am I barking up the wrong tree with OpenLdap?


On Tue, May 14, 2013 at 4:38 PM, Dan White <dwhite@olp.net> wrote:

On 05/14/13 15:28 +0100, Stuart Watson wrote:
Sorry, i'm confused....

I've been asked to setup a LDAP server so that our developers can SSH from
their computers to remote systems, through the LDAP server, giving us the
ability to control who can ssh.....

"Through the LDAP server" is a misnomer, and may be leading to some
confusion.

You are simply using OpenLDAP as a database here, like MySQL, and nothing
more. You're storing your keys within that database. You're not storing
your system users in that database apparently, due to the error message
you're seeing.

When ssh'ing to the server, key authentication may be succeeding (increase
ssh client verbosity to verify). I don't know the details of the patch
you've applied, but I assume that it does not take the place of a getpwent
system call, and hence you will need to configure a system user (so that
ssh knows where the user's home directory is, for instance).

I've spent the last few days trawlling through the documentation, and get
as far as having the ldap server setup, but can't seem to get any further.

Do I need to add local accounts to the LDAP server?

Yes. That's the simplest way forward. You can disable the user's password
if you don't want password authentication to succeed (or disable pam auth
in sshd_config).

An alternative is that you can configure an nss ldap plugin to interpret your
LDAP data as system users, but that's an independent concept from how you
store your ssh keys.

What we were trying to achieve was


User > Ldap Server > Remote Server

with the Remote server pointing at the ldap server for authentication, thus
stopping us from creating local accounts and from adding ssh keys to the
Remote Servers.

You can't get away from creating local accounts with ssh (barring some
trick your patch is performing). You can "trick" ssh into using accounts
stored within your ldap tree by using an nss module.

As I've stated before, you need 'getent passwd <user>' to work, or you're
going to continue to bang your head against the wall.

--
Dan White