diff -up openssh-5.8p1/HOWTO.ldap-keys.ldap2 openssh-5.8p1/HOWTO.ldap-keys --- openssh-5.8p1/HOWTO.ldap-keys.ldap2 2011-03-10 21:45:52.706855323 +0100 +++ openssh-5.8p1/HOWTO.ldap-keys 2011-03-10 19:35:50.000000000 +0100 @@ -1,14 +1,108 @@ +HOW TO START + 1) configure LDAP server -2) add appropriate schema + * Use LDAP server documentation +2) add appropriate LDAP schema + * For OpenLDAP or SunONE Use attached schema, otherwise you have to create it. + * LDAP user entry + User entry: + - attached to the 'ldapPublicKey' objectclass + - attached to the 'posixAccount' objectclass + - with a filled 'sshPublicKey' attribute 3) insert users into LDAP + * Use LDAP Tree management tool as useful + * Entry in the LDAP server must respect 'posixAccount' and 'ldapPublicKey' which are defined in core.schema and the additionnal lpk.schema. + * Example: + dn: uid=captain,ou=commanders,dc=enterprise,dc=universe + objectclass: top + objectclass: person + objectclass: organizationalPerson + objectclass: posixAccount + objectclass: ldapPublicKey + description: Jonathan Archer + userPassword: Porthos + cn: onathan Archer + sn: onathan Archer + uid: captain + uidNumber: 1001 + gidNumber: 1001 + homeDirectory: /home/captain + sshPublicKey: ssh-rss AAAAB3.... =captain@universe + sshPublicKey: command="kill -9 1" ssh-rss AAAAM5... 4) on the ssh side set in sshd_config -AuthorizedKeysCommand "/usr/libexec/openssh/ssh-ldap-wrapper" -AuthorizedKeysCommandRunAs -5) do not forget to set -PubkeyAuthentication yes + * Set up the backend + AuthorizedKeysCommand "/usr/libexec/openssh/ssh-ldap-wrapper" + AuthorizedKeysCommandRunAs + * Do not forget to set + PubkeyAuthentication yes + * Swith off unnecessary auth methods +5) confugure ldap.conf + * Default ldap.conf is placed in /etc/ssh + * The configuration style is the same as other ldap based aplications +6) if necessary edit ssh-ldap-wrapper + * There is a possibility to change ldap.conf location + * There are some debug options + * Example + /usr/libexec/openssh -s -f /etc/ldap.conf -w -d >> /tmp/ldapdebuglog.txt + +HOW TO MIGRATE FROM LPK + +1) goto HOW TO START 4) .... the ldap schema is the same + +2) convert the group requests to the appropriate LDAP requests + +HOW TO SOLVE PROBLEMS + +1) use debug in sshd + * /usr/sbin/sshd -d -d -d -d +2) use debug in ssh-ldap-helper + * ssh-ldap-helper -d -d -d -d -s +3) use tcpdump ... other ldap client etc. + +ADVANTAGES + +1) Blocking an user account can be done directly from LDAP (if sshd is using PubkeyAuthentication + AuthorizedKeysCommand with ldap only). + +DISADVANTAGES + +1) LDAP must be well configured, getting the public key of some user is not a problem, but if anonymous LDAP + allows write to users dn, somebody could replace some user's public key by his own and impersonate some + of your users in all your server farm -- be VERY CAREFUL. +2) With incomplete PKI the MITM attack when sshd is requesting the public key, could lead to a compromise of your servers allowing login + as the impersonated user. +3) If LDAP server is down there may be no fallback on passwd auth. + +MISC. + +1) todo + * Possibility to reuse the ssh-ldap-helper. + * Tune the LDAP part to accept all possible LDAP configurations. + +2) differences from original lpk + * No LDAP code in sshd. + * Support for various LDAP platforms and configurations. + * LDAP is configured in separate ldap.conf file. + +3) docs/link + * http://pacsec.jp/core05/psj05-barisani-en.pdf + * http://fritz.potsdam.edu/projects/openssh-lpk/ + * http://fritz.potsdam.edu/projects/sshgate/ + * http://dev.inversepath.com/trac/openssh-lpk + * http://lam.sf.net/ ( http://lam.sourceforge.net/documentation/supportedSchemas.htm ) +4) contributors/ideas/greets + - Eric AUGE + - Andrea Barisani + - Falk Siemonsmeier. + - Jacob Rief. + - Michael Durchgraf. + - frederic peters. + - Finlay dobbie. + - Stefan Fisher. + - Robin H. Johnson. + - Adrian Bridgett. -To debug the ssh-ldap-helper is possible to set -the necessary flags in the ssh-ldap-wrapper. +5) Author + Jan F. Chadima diff -up openssh-5.8p1/ldap-helper.c.ldap2 openssh-5.8p1/ldap-helper.c --- openssh-5.8p1/ldap-helper.c.ldap2 2011-03-10 21:45:52.872854838 +0100 +++ openssh-5.8p1/ldap-helper.c 2011-03-10 21:45:53.342855061 +0100 @@ -138,6 +138,7 @@ main(int ac, char **av) if (config_single_user) { process_user (config_single_user, outfile); } else { + usage(); fatal ("Not yet implemented"); /* TODO * open unix socket a run the loop on it diff -up openssh-5.8p1/lpk-user-example.txt.ldap2 openssh-5.8p1/lpk-user-example.txt --- openssh-5.8p1/lpk-user-example.txt.ldap2 2011-03-10 21:45:52.986980339 +0100 +++ openssh-5.8p1/lpk-user-example.txt 2011-03-10 21:45:53.379854929 +0100 @@ -1,117 +0,0 @@ - -Post to ML -> User Made Quick Install Doc. -Contribution from John Lane - -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - -OpenSSH LDAP keystore Patch -=========================== - -NOTE: these notes are a transcript of a specific installation - they work for me, your specifics may be different! - from John Lane March 17th 2005 john@lane.uk.net - -This is a patch to OpenSSH 4.0p1 to allow it to obtain users' public keys -from their LDAP record as an alternative to ~/.ssh/authorized_keys. - -(Assuming here that necessary build stuff is in $BUILD) - -cd $BUILD/openssh-4.0p1 -patch -Np1 -i $BUILD/openssh-lpk-4.0p1-0.3.patch -mkdir -p /var/empty && -./configure --prefix=/usr --sysconfdir=/etc/ssh \ - --libexecdir=/usr/sbin --with-md5-passwords --with-pam \ - --with-libs="-lldap" --with-cppflags="-DWITH_LDAP_PUBKEY" -Now do. -make && -make install - -Add the following config to /etc/ssh/ssh_config -UseLPK yes -LpkServers ldap://myhost.mydomain.com -LpkUserDN ou=People,dc=mydomain,dc=com - -We need to tell sshd about the SSL keys during boot, as root's -environment does not exist at that time. Edit /etc/rc.d/init.d/sshd. -Change the startup code from this: - echo "Starting SSH Server..." - loadproc /usr/sbin/sshd - ;; -to this: - echo "Starting SSH Server..." - LDAPRC="/root/.ldaprc" loadproc /usr/sbin/sshd - ;; - -Re-start the sshd daemon: -/etc/rc.d/init.d/sshd restart - -Install the additional LDAP schema -cp $BUILD/openssh-lpk-0.2.schema /etc/openldap/schema/openssh.schema - -Now add the openSSH LDAP schema to /etc/openldap/slapd.conf: -Add the following to the end of the existing block of schema includes -include /etc/openldap/schema/openssh.schema - -Re-start the LDAP server: -/etc/rc.d/init.d/slapd restart - -To add one or more public keys to a user, eg "testuser" : -ldapsearch -x -W -Z -LLL -b "uid=testuser,ou=People,dc=mydomain,dc=com" -D -"uid=testuser,ou=People,dc=mydomain,dc=com" > /tmp/testuser - -append the following to this /tmp/testuser file -objectclass: ldapPublicKey -sshPublicKey: ssh-rsa -AAAAB3NzaC1yc2EAAAABJQAAAIB3dsrwqXqD7E4zYYrxwdDKBUQxKMioXy9pxFVai64kAPxjU9KS -qIo7QfkjslfsjflksjfldfkjsldfjLX/5zkzRmT28I5piGzunPv17S89z8XwSsuAoR1t86t+5dlI -7eZE/gVbn2UQkQq7+kdDTS2yXV6VnC52N/kKLG3ciBkBAw== General Purpose RSA Key - -Then do a modify: -ldapmodify -x -D "uid=testuser,ou=People,dc=mydomain,dc=com" -W -f -/tmp/testuser -Z -Enter LDAP Password: -modifying entry "uid=testuser,ou=People,dc=mydomain,dc=com" -And check the modify is ok: -ldapsearch -x -W -Z -b "uid=testuser,ou=People,dc=mydomain,dc=com" -D -"uid=testuser,ou=People,dc=mydomain,dc=com" -Enter LDAP Password: -# extended LDIF -# -# LDAPv3 -# base with scope sub -# filter: (objectclass=*) -# requesting: ALL -# - -# testuser, People, mydomain.com -dn: uid=testuser,ou=People,dc=mydomain,dc=com -uid: testuser -cn: testuser -objectClass: account -objectClass: posixAccount -objectClass: top -objectClass: shadowAccount -objectClass: ldapPublicKey -shadowLastChange: 12757 -shadowMax: 99999 -shadowWarning: 7 -loginShell: /bin/bash -uidNumber: 9999 -gidNumber: 501 -homeDirectory: /home/testuser -userPassword:: e1NTSEF9UDgwV1hnM1VjUDRJK0k1YnFiL1d4ZUJObXlZZ3Z3UTU= -sshPublicKey: ssh-rsa -AAAAB3NzaC1yc2EAAAABJQAAAIB3dsrwqXqD7E4zYYrxwdDKBUQxKMioXy9pxFVai64kAPxjU9KSqIo7QfkjslfsjflksjfldfkjsldfjLX/5zkzRmT28I5piGzunPv17S89z -8XwSsuAoR1t86t+5dlI7eZE/gVbn2UQkQq7+kdDTS2yXV6VnC52N/kKLG3ciBkBAw== General Purpose RSA Key - -# search result -search: 3 -result: 0 Success - -# numResponses: 2 -# numEntries: 1 - -Now start a ssh session to user "testuser" from usual ssh client (e.g. -puTTY). Login should succeed. - -++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ diff -up openssh-5.8p1/README.lpk.ldap2 openssh-5.8p1/README.lpk --- openssh-5.8p1/README.lpk.ldap2 2011-03-10 21:45:53.112979980 +0100 +++ openssh-5.8p1/README.lpk 2011-03-10 21:45:53.416856007 +0100 @@ -1,274 +0,0 @@ -OpenSSH LDAP PUBLIC KEY PATCH -Copyright (c) 2003 Eric AUGE (eau@phear.org) -All rights reserved. - -Rewriten by Jan F. Chadima (jchadima@redhat.com) -Copyright (c) 2010 Red Hat, Inc. -The new PKA-LDAP patch is rewritten from the scratch. -LDAP schema and part of the documentation is based on original -LPK project (http://code.google.com/p/openssh-lpk), -copyright (c) 2003 Eric AUGE -The new openssh configuration is different from the original LPK one. - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions -are met: -1. Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. -2. Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. -3. The name of the author may not be used to endorse or promote products - derived from this software without specific prior written permission. - -THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR -IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES -OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. -IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, -INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT -NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF -THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -purposes of this patch: - -This patch would help to have authentication centralization policy -using ssh public key authentication. -This patch could be an alternative to other "secure" authentication system -working in a similar way (Kerberos, SecurID, etc...), except the fact -that it's based on OpenSSH and its public key abilities. - ->> FYI: << -'uid': means unix accounts existing on the current server -'ServerGroup:' mean server group configured on the current server by the SSH_Filter option in the ldap.conf. - -example schema: - - - server1 (uid: eau,rival,toto) (ServerGroup: unix) - ___________ / - / \ --- - server3 (uid: eau, titi) (ServerGroup: unix) - | LDAP Server | \ - | eau ,rival | server2 (uid: rival, eau) (ServerGroup: unix) - | titi ,toto | - | userx,.... | server5 (uid: eau) (ServerGroup: mail) - \___________/ \ / - ----- - server4 (uid: eau, rival) (no group configured) - \ - etc... - -- WHAT WE NEED : - - * configured LDAP server somewhere on the network (i.e. OpenLDAP) - * patched sshd (with this patch ;) - * LDAP user(/group) entry (look at users.ldif (& groups.ldif)): - User entry: - - attached to the 'ldapPublicKey' objectclass - - attached to the 'posixAccount' objectclass - - with a filled 'sshPublicKey' attribute - Example: - dn: uid=eau,ou=users,dc=cuckoos,dc=net - objectclass: top - objectclass: person - objectclass: organizationalPerson - objectclass: posixAccount - objectclass: ldapPublicKey - description: Eric AUGE Account - userPassword: blah - cn: Eric AUGE - sn: Eric AUGE - uid: eau - uidNumber: 1034 - gidNumber: 1 - homeDirectory: /export/home/eau - sshPublicKey: ssh-dss AAAAB3... - sshPublicKey: ssh-dss AAAAM5... - - Group entry: - - attached to the 'posixGroup' objectclass - - with a 'cn' groupname attribute - - with multiple 'memberUid' attributes filled with usernames allowed in this group - Example: - # few members - dn: cn=unix,ou=groups,dc=cuckoos,dc=net - objectclass: top - objectclass: posixGroup - description: Unix based servers group - cn: unix - gidNumber: 1002 - memberUid: eau - memberUid: user1 - memberUid: user2 - - -- HOW IT WORKS : - - * without patch - If a user wants to authenticate to log in a server the sshd, will first look for authentication method allowed (RSAauth,kerberos,etc..) - and if RSAauth and tickets based auth fails, it will fallback to standard password authentication (if enabled). - - * with the patch - If a user want to authenticate to log in a server, the sshd will first look for auth method including LDAP pubkey, if the ldappubkey options is enabled. - It will do an ldapsearch to get the public key directly from the LDAP instead of reading it from the server filesystem. - (usually in $HOME/.ssh/authorized_keys) - - 2 tokens are added to sshd_config : - # here is the new patched ldap related tokens - AuthorizedKeysCommand "/usr/libexec/openssh/ssh-ldap-wrapper" - AuthorizedKeysCommandRunAs nobody - - The LDAP configuratin is read from common /etc/ldap.conf configuration file. -There is also one optional parameter in the LDAP configuration file, SSH_Filter, which is a LDAP filter limiting keys to be searched. - -- HOW TO INSERT A USER/KEY INTO AN LDAP ENTRY - - * my way (there is plenty :) - - create ldif file (i.e. users.ldif) - - cat ~/.ssh/id_dsa.pub OR cat ~/.ssh/id_rsa.pub OR cat ~/.ssh/identity.pub - - my way in 4 steps : - Example: - - # you add this to the user entry in the LDIF file : - [...] - objectclass: posixAccount - objectclass: ldapPublicKey - [...] - sshPubliKey: ssh-dss AAAABDh12DDUR2... - [...] - - # insert your entry and you're done :) - ldapadd -D balblabla -w bleh < file.ldif - - all standard options can be present in the 'sshPublicKey' attribute. - -- WHY : - - Simply because, i was looking for a way to centralize all sysadmins authentication, easily, without completely using LDAP - as authentication method (like pam_ldap etc..). - - After looking into Kerberos, SecurID, and other centralized secure authentications systems, the use of RSA and LDAP to get - public key for authentication allows us to control who has access to which server (the user needs an account and to be in 'strongAuthenticationUser' - objectclass within LDAP and part of the group the SSH server is in). - - Passwords update are no longer a nightmare for a server farm (key pair passphrase is stored on each user's box and private key is locally encrypted using his passphrase - so each user can change it as much as he wants). - - Blocking a user account can be done directly from the LDAP (if sshd is using RSAAuth + ldap only). - -- RULES : - Entry in the LDAP server must respect 'posixAccount' and 'ldapPublicKey' which are defined in core.schema. - and the additionnal lpk.schema. - - This patch could allow a smooth transition between standard auth (/etc/passwd) and complete LDAP based authentication - (pamldap, nss_ldap, etc..). - - This can be an alternative to other (old?/expensive?) authentication methods (Kerberos/SecurID/..). - - Referring to schema at the beginning of this file if user 'eau' is only in group 'unix' - 'eau' would ONLY access 'server1', 'server2', 'server3' AND 'server4' BUT NOT 'server5'. - If you then modify the LDAP 'mail' group entry to add 'memberUid: eau' THEN user 'eau' would be able - to log in 'server5' (i hope you got the idea, my english is bad :). - - Each server's sshd is patched and configured to ask the public key and the group infos in the LDAP - server. - When you want to allow a new user to have access to the server parc, you just add him an account on - your servers, you add his public key into his entry on the LDAP server, it's done. - - Because sshds are looking public keys into the LDAP directly instead of a file ($HOME/.ssh/authorized_keys). - - When the user needs to change his passphrase he can do it directly from his workstation by changing - his own key set lock passphrase, and all servers are automatically aware. - - With a CAREFUL LDAP server configuration you could allow a user to add/delete/modify his own entry himself - so he can add/modify/delete himself his public key when needed. - -­ FLAWS : - LDAP must be well configured, getting the public key of some user is not a problem, but if anonymous LDAP - allow write to users dn, somebody could replace someuser's public key by its own and impersonate some - of your users in all your server farm be VERY CAREFUL. - - MITM attack when sshd is requesting the public key, could lead to a compromise of your servers allowing login - as the impersonnated user. - - If LDAP server is down then, no fallback on passwd auth. - - the ldap code part has not been well audited yet. - -- LDAP USER ENTRY EXAMPLES (LDIF Format, look in users.ldif) - --- CUT HERE --- - dn: uid=jdoe,ou=users,dc=foobar,dc=net - objectclass: top - objectclass: person - objectclass: organizationalPerson - objectclass: posixAccount - objectclass: ldapPublicKey - description: My account - cn: John Doe - sn: John Doe - uid: jdoe - uidNumber: 100 - gidNumber: 100 - homeDirectory: /home/jdoe - sshPublicKey: ssh-dss AAAAB3NzaC1kc3MAAAEBAOvL8pREUg9wSy/8+hQJ54YF3AXkB0OZrXB.... - [...] - --- CUT HERE --- - -- LDAP GROUP ENTRY EXAMPLES (LDIF Format, look in groups.ldif) - --- CUT HERE --- - dn: cn=unix,ou=groups,dc=cuckoos,dc=net - objectclass: top - objectclass: posixGroup - description: Unix based servers group - cn: unix - gidNumber: 1002 - memberUid: jdoe - memberUid: user1 - memberUid: user2 - [...] - --- CUT HERE --- - ->> FYI: << -Multiple 'sshPublicKey' in a user entry are allowed, as well as multiple 'memberUid' attributes in a group entry - -- COMPILING: - 1. Apply the patch - 2. ./configure --with-your-options --with-ldap=/prefix/to/ldap_libs_and_includes - 3. make - 4. it's done. - -- BLA : - I hope this could help, and i hope to be clear enough,, or give ideas. questions/comments/improvements are welcome. - -- TODO : - Possibility to reuse the ssh-ldap-helper. - Tune the LDAP part to all possible LDAP configurations. - -- DIFFERENCES FROM ORIGINAL lpk - No LDAP code in sshd. - Support for various LDAP platforms and configurations. - LDAP is configured in separate ldap.conf file. - -- DOCS/LINK : - http://pacsec.jp/core05/psj05-barisani-en.pdf - http://fritz.potsdam.edu/projects/openssh-lpk/ - http://fritz.potsdam.edu/projects/sshgate/ - http://dev.inversepath.com/trac/openssh-lpk - http://lam.sf.net/ ( http://lam.sourceforge.net/documentation/supportedSchemas.htm ) - -- CONTRIBUTORS/IDEAS/GREETS : - - Eric AUGE - - Andrea Barisani - - Falk Siemonsmeier. - - Jacob Rief. - - Michael Durchgraf. - - frederic peters. - - Finlay dobbie. - - Stefan Fisher. - - Robin H. Johnson. - - Adrian Bridgett. - -- CONTACT : - Jan F. Chadima - diff -up openssh-5.8p1/ssh-ldap-helper.8.ldap2 openssh-5.8p1/ssh-ldap-helper.8 --- openssh-5.8p1/ssh-ldap-helper.8.ldap2 2011-03-10 21:45:53.170854817 +0100 +++ openssh-5.8p1/ssh-ldap-helper.8 2011-03-10 21:45:53.454980272 +0100 @@ -37,11 +37,12 @@ sshd configuration file by setting .Cm AuthorizedKeysCommand to -.Dq /usr/libexec/ssh-ldap-helper -s %u . +.Dq /usr/libexec/ssh-ldap-wrapper . .Pp .Nm is not intended to be invoked by the user, but from -.Xr sshd 8 . +.Xr sshd 8 via +.Xr ssh-ldap-wrapper . .Pp The options are as follows: .Bl -tag -width Ds