[openssh] improove ssh-ldap (documentation)
Jan F. Chadima
jfch2222 at fedoraproject.org
Thu Mar 10 17:26:33 UTC 2011
commit 9404cdd3e31292d8b80133d1299e11da31c1d08b
Author: Jan F <jfch at kerberos.example.com>
Date: Thu Mar 10 18:26:11 2011 +0100
improove ssh-ldap (documentation)
openssh-5.8p1-ldap2.patch | 547 +++++++++++++++++++++++++++++++++++++++++++++
openssh.spec | 9 +-
2 files changed, 553 insertions(+), 3 deletions(-)
---
diff --git a/openssh-5.8p1-ldap2.patch b/openssh-5.8p1-ldap2.patch
index e69de29..425b623 100644
--- a/openssh-5.8p1-ldap2.patch
+++ b/openssh-5.8p1-ldap2.patch
@@ -0,0 +1,547 @@
+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 18:22:10.469855868 +0100
++++ openssh-5.8p1/HOWTO.ldap-keys 2011-03-10 18:22:11.018980430 +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 at 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 &tc..
++
++ADWANTAGES
++
++1) Blocking a user account can be done directly from the 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
++ 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.
++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 impersonnated user.
++3 If LDAP server is down then ma be no fallback on passwd auth.
++
++MISC.
++
++1) todo
++ * Possibility to reuse the ssh-ldap-helper.
++ * Tune the LDAP part to 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 at phear.org>
++ - Andrea Barisani <andrea at 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 at 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 18:22:48.870980079 +0100
++++ openssh-5.8p1/ldap-helper.c 2011-03-10 18:07:41.000000000 +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 18:22:10.745854874 +0100
++++ openssh-5.8p1/lpk-user-example.txt 2011-03-10 18:22:11.053980912 +0100
+@@ -1,117 +0,0 @@
+-
+-Post to ML -> User Made Quick Install Doc.
+-Contribution from John Lane <john at 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 at 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 18:22:10.872981060 +0100
++++ openssh-5.8p1/README.lpk 2011-03-10 18:22:11.089980853 +0100
+@@ -1,274 +0,0 @@
+-OpenSSH LDAP PUBLIC KEY PATCH
+-Copyright (c) 2003 Eric AUGE (eau at phear.org)
+-All rights reserved.
+-
+-Rewriten by Jan F. Chadima (jchadima at 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 <eau at phear.org>
+- - Andrea Barisani <andrea at inversepath.com>
+- - Falk Siemonsmeier.
+- - Jacob Rief.
+- - Michael Durchgraf.
+- - frederic peters.
+- - Finlay dobbie.
+- - Stefan Fisher.
+- - Robin H. Johnson.
+- - Adrian Bridgett.
+-
+-- CONTACT :
+- Jan F. Chadima <jchadima at 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 18:22:10.921854948 +0100
++++ openssh-5.8p1/ssh-ldap-helper.8 2011-03-10 18:20:17.000000000 +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
diff --git a/openssh.spec b/openssh.spec
index b913f3d..1331976 100644
--- a/openssh.spec
+++ b/openssh.spec
@@ -71,7 +71,7 @@
# Do not forget to bump pam_ssh_agent_auth release if you rewind the main package release to 1
%define openssh_ver 5.8p1
-%define openssh_rel 16
+%define openssh_rel 17
%define pam_ssh_agent_ver 0.9.2
%define pam_ssh_agent_rel 30
@@ -622,7 +622,7 @@ fi
%if %{ldap}
%files ldap
%defattr(-,root,root)
-%doc HOWTO.ldap-keys README.lpk lpk-user-example.txt openssh-lpk-openldap.schema openssh-lpk-sun.schema ldap.conf
+%doc HOWTO.ldap-keys openssh-lpk-openldap.schema openssh-lpk-sun.schema ldap.conf
%attr(0755,root,root) %{_libexecdir}/openssh/ssh-ldap-helper
%attr(0755,root,root) %{_libexecdir}/openssh/ssh-ldap-wrapper
%attr(0644,root,root) %{_mandir}/man8/ssh-ldap-helper.8*
@@ -652,6 +652,9 @@ fi
%endif
%changelog
+* Thu Mar 10 2011 Jan F. Chadima <jchadima at redhat.com> - 5.8p1-17 + 0.9.2-30
+- improove ssh-ldap (documentation)
+
* Tue Mar 8 2011 Jan F. Chadima <jchadima at redhat.com> - 5.8p1-16 + 0.9.2-30
- improve session keys audit
@@ -659,7 +662,7 @@ fi
- CVE-2010-4755
* Fri Mar 4 2011 Jan F. Chadima <jchadima at redhat.com> - 5.8p1-14 + 0.9.2-30
-- improove ssk-keycat (documentation)
+- improove ssh-keycat (documentation)
* Thu Mar 3 2011 Jan F. Chadima <jchadima at redhat.com> - 5.8p1-13 + 0.9.2-30
- improve audit of logins and auths
More information about the scm-commits
mailing list