jonathan/openssh
1
0
Fork 0
forked from rpms/openssh
Code Pull Requests Activity
0f7ccbf444
openssh/openssh-5.8p1-ldap2.patch
Jan F 9992a8e919 improove ssh-ldap (documentation)
2011-03-10 21:48:09 +01:00

548 lines
20 KiB
Diff
Raw Blame History

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 <appropriate user to run LDAP>
-5) do not forget to set
-PubkeyAuthentication yes
+ * Set up the backend
+ AuthorizedKeysCommand "/usr/libexec/openssh/ssh-ldap-wrapper"
+ AuthorizedKeysCommandRunAs <appropriate user to run LDAP>
+ * 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 <username>
+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 <eau@phear.org>
+ - Andrea Barisani <andrea@inversepath.com>
+ - 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 <jchadima@redhat.com>
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 <john@lane.uk.net>
-
-++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-
-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 <uid=testuser,ou=People,dc=mydomain,dc=com> 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.<2E>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.
-
-<2D> 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 <eau@phear.org>
- - Andrea Barisani <andrea@inversepath.com>
- - Falk Siemonsmeier.
- - Jacob Rief.
- - Michael Durchgraf.
- - frederic peters.
- - Finlay dobbie.
- - Stefan Fisher.
- - Robin H. Johnson.
- - Adrian Bridgett.
-
-- CONTACT :
- Jan F. Chadima <jchadima@redhat.com>
-
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
View Git Blame Copy Permalink