On 4/4/07, Vic Cross <[EMAIL PROTECTED]> wrote:
This OpenSSH patch[1] is (IMHO) in need of more "airplay". AFAIK Gentoo is the only distro that includes it as part of their OpenSSH package (I don't have SLES10 or RHEL5 nearby, they may have finally picked it up).
Yes, it does solves some problems, which is why I wanted to use it. We ended up removing all passwords and only allow authentication by cryptic keys. The root password was also gone, and access was entirely through sudo (without password obviously -the LDAP database also defined which users on what system were in the group that could use sudo). And managed routine processes that needed root access would go through the SCIF interface to the already logged-on root account. Suppose the primary reason of OpenSSH-LPK not being mainstream is that it is a bit of a quick hack. The author did some ad-hoc schema to stuff the public key into LDAP. What you really want is to have a user certificate in the database (the public key signed by some trusted authority). This avoids the need to trust the LDAP server (or fall-back mirror) on its blue eyes only. The other part that I would like to see is to hold the host public keys as well, instead of every user end up with copies in his private storage (and not being surprised when they don't match).
For shops using LDAP for authentication, it makes a lot of sense -- you can have all your user detail in a sturdy LDAP directory, and using appropriate filter configurations for nss_ldap and pam_ldap you can still provide per-server access control[2]. The 'uploading' of the key can be done with any of the LDAP administration tools, such as phpldapadmin, LAM, or Luma -- the authorised key is just an ASCII text field so cut-and-paste will work.
I know some installations automated maintaining copies of authorized_keys (at least for root) by replication from a master so that all required public keys were there when needed. But the security policy was that the user should be able to have his public key removed when compromised. That's hard to do when you don't know where it is kept (and a compromised system may be modified not to remove the key when the master is changed). Having it in one place makes it possible for the user to manage it.
Another method that works is to share user home directories via NFS. When a user logs on to a system their home directory is automounted, which makes their ~/.ssh/ and consequently their authorised keys available.
This caused a problem for us with developers who could have root access on their development system but not on production servers. If they could mount my home directory on their development system they could put extra keys in my authorized_keys file and then have that automount on production systems as well to gain root access. It may be helpful to distinguish between daily use and exceptional access to systems. I worked with folks who moved all their daily system admin stuff into cfengine and other managed processes. That avoided the need for support staff to login on production systems, and doing so would need to be justified by a problem ticket. If you can get that far the requirements are different. Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
