1OpenSSH LDAP PUBLIC KEY PATCH 2Copyright (c) 2003 Eric AUGE (eau@phear.org) 3All rights reserved. 4 5Redistribution and use in source and binary forms, with or without 6modification, are permitted provided that the following conditions 7are met: 81. Redistributions of source code must retain the above copyright 9 notice, this list of conditions and the following disclaimer. 102. Redistributions in binary form must reproduce the above copyright 11 notice, this list of conditions and the following disclaimer in the 12 documentation and/or other materials provided with the distribution. 133. The name of the author may not be used to endorse or promote products 14 derived from this software without specific prior written permission. 15 16THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR 17IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 18OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 19IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, 20INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 21NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 22DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 23THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 24(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 25THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 26 27purposes of this patch: 28 29This patch would help to have authentication centralization policy 30using ssh public key authentication. 31This patch could be an alternative to other "secure" authentication system 32working in a similar way (Kerberos, SecurID, etc...), except the fact 33that it's based on OpenSSH and its public key abilities. 34 35>> FYI: << 36'uid': means unix accounts existing on the current server 37'lpkServerGroup:' mean server group configured on the current server ('lpkServerGroup' in sshd_config) 38 39example schema: 40 41 42 server1 (uid: eau,rival,toto) (lpkServerGroup: unix) 43 ___________ / 44 / \ --- - server3 (uid: eau, titi) (lpkServerGroup: unix) 45 | LDAP Server | \ 46 | eau ,rival | server2 (uid: rival, eau) (lpkServerGroup: unix) 47 | titi ,toto | 48 | userx,.... | server5 (uid: eau) (lpkServerGroup: mail) 49 \___________/ \ / 50 ----- - server4 (uid: eau, rival) (no group configured) 51 \ 52 etc... 53 54- WHAT WE NEED : 55 56 * configured LDAP server somewhere on the network (i.e. OpenLDAP) 57 * patched sshd (with this patch ;) 58 * LDAP user(/group) entry (look at users.ldif (& groups.ldif)): 59 User entry: 60 - attached to the 'ldapPublicKey' objectclass 61 - attached to the 'posixAccount' objectclass 62 - with a filled 'sshPublicKey' attribute 63 Example: 64 dn: uid=eau,ou=users,dc=cuckoos,dc=net 65 objectclass: top 66 objectclass: person 67 objectclass: organizationalPerson 68 objectclass: posixAccount 69 objectclass: ldapPublicKey 70 description: Eric AUGE Account 71 userPassword: blah 72 cn: Eric AUGE 73 sn: Eric AUGE 74 uid: eau 75 uidNumber: 1034 76 gidNumber: 1 77 homeDirectory: /export/home/eau 78 sshPublicKey: ssh-dss AAAAB3... 79 sshPublicKey: ssh-dss AAAAM5... 80 81 Group entry: 82 - attached to the 'posixGroup' objectclass 83 - with a 'cn' groupname attribute 84 - with multiple 'memberUid' attributes filled with usernames allowed in this group 85 Example: 86 # few members 87 dn: cn=unix,ou=groups,dc=cuckoos,dc=net 88 objectclass: top 89 objectclass: posixGroup 90 description: Unix based servers group 91 cn: unix 92 gidNumber: 1002 93 memberUid: eau 94 memberUid: user1 95 memberUid: user2 96 97 98- HOW IT WORKS : 99 100 * without patch 101 If a user wants to authenticate to log in a server the sshd, will first look for authentication method allowed (RSAauth,kerberos,etc..) 102 and if RSAauth and tickets based auth fails, it will fallback to standard password authentication (if enabled). 103 104 * with the patch 105 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. 106 It will do an ldapsearch to get the public key directly from the LDAP instead of reading it from the server filesystem. 107 (usually in $HOME/.ssh/authorized_keys) 108 109 If groups are enabled, it will also check if the user that wants to login is in the group of the server he is trying to log into. 110 If it fails, it falls back on RSA auth files ($HOME/.ssh/authorized_keys), etc.. and finally to standard password authentication (if enabled). 111 112 7 tokens are added to sshd_config : 113 # here is the new patched ldap related tokens 114 # entries in your LDAP must be posixAccount & strongAuthenticationUser & posixGroup 115 UseLPK yes # look the pub key into LDAP 116 LpkServers ldap://10.31.32.5/ ldap://10.31.32.4 ldap://10.31.32.3 # which LDAP server for users ? (URL format) 117 LpkUserDN ou=users,dc=foobar,dc=net # which base DN for users ? 118 LpkGroupDN ou=groups,dc=foobar,dc=net # which base DN for groups ? 119 LpkBindDN cn=manager,dc=foobar,dc=net # which bind DN ? 120 LpkBindPw asecret # bind DN credidentials 121 LpkServerGroup agroupname # the group the server is part of 122 123 Right now i'm using anonymous binding to get public keys, because getting public keys of someone doesn't impersonate him� but there is some 124 flaws you have to take care of. 125 126- HOW TO INSERT A USER/KEY INTO AN LDAP ENTRY 127 128 * my way (there is plenty :) 129 - create ldif file (i.e. users.ldif) 130 - cat ~/.ssh/id_dsa.pub OR cat ~/.ssh/id_rsa.pub OR cat ~/.ssh/identity.pub 131 - my way in 4 steps : 132 Example: 133 134 # you add this to the user entry in the LDIF file : 135 [...] 136 objectclass: posixAccount 137 objectclass: ldapPublicKey 138 [...] 139 sshPubliKey: ssh-dss AAAABDh12DDUR2... 140 [...] 141 142 # insert your entry and you're done :) 143 ldapadd -D balblabla -w bleh < file.ldif 144 145 all standard options can be present in the 'sshPublicKey' attribute. 146 147- WHY : 148 149 Simply because, i was looking for a way to centralize all sysadmins authentication, easily, without completely using LDAP 150 as authentication method (like pam_ldap etc..). 151 152 After looking into Kerberos, SecurID, and other centralized secure authentications systems, the use of RSA and LDAP to get 153 public key for authentication allows us to control who has access to which server (the user needs an account and to be in 'strongAuthenticationUser' 154 objectclass within LDAP and part of the group the SSH server is in). 155 156 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 157 so each user can change it as much as he wants). 158 159 Blocking a user account can be done directly from the LDAP (if sshd is using RSAAuth + ldap only). 160 161- RULES : 162 Entry in the LDAP server must respect 'posixAccount' and 'ldapPublicKey' which are defined in core.schema. 163 and the additionnal lpk.schema. 164 165 This patch could allow a smooth transition between standard auth (/etc/passwd) and complete LDAP based authentication 166 (pamldap, nss_ldap, etc..). 167 168 This can be an alternative to other (old?/expensive?) authentication methods (Kerberos/SecurID/..). 169 170 Referring to schema at the beginning of this file if user 'eau' is only in group 'unix' 171 'eau' would ONLY access 'server1', 'server2', 'server3' AND 'server4' BUT NOT 'server5'. 172 If you then modify the LDAP 'mail' group entry to add 'memberUid: eau' THEN user 'eau' would be able 173 to log in 'server5' (i hope you got the idea, my english is bad :). 174 175 Each server's sshd is patched and configured to ask the public key and the group infos in the LDAP 176 server. 177 When you want to allow a new user to have access to the server parc, you just add him an account on 178 your servers, you add his public key into his entry on the LDAP server, it's done. 179 180 Because sshds are looking public keys into the LDAP directly instead of a file ($HOME/.ssh/authorized_keys). 181 182 When the user needs to change his passphrase he can do it directly from his workstation by changing 183 his own key set lock passphrase, and all servers are automatically aware. 184 185 With a CAREFUL LDAP server configuration you could allow a user to add/delete/modify his own entry himself 186 so he can add/modify/delete himself his public key when needed. 187 188� FLAWS : 189 LDAP must be well configured, getting the public key of some user is not a problem, but if anonymous LDAP 190 allow write to users dn, somebody could replace someuser's public key by its own and impersonate some 191 of your users in all your server farm be VERY CAREFUL. 192 193 MITM attack when sshd is requesting the public key, could lead to a compromise of your servers allowing login 194 as the impersonnated user. 195 196 If LDAP server is down then, fallback on passwd auth. 197 198 the ldap code part has not been well audited yet. 199 200- LDAP USER ENTRY EXAMPLES (LDIF Format, look in users.ldif) 201 --- CUT HERE --- 202 dn: uid=jdoe,ou=users,dc=foobar,dc=net 203 objectclass: top 204 objectclass: person 205 objectclass: organizationalPerson 206 objectclass: posixAccount 207 objectclass: ldapPublicKey 208 description: My account 209 cn: John Doe 210 sn: John Doe 211 uid: jdoe 212 uidNumber: 100 213 gidNumber: 100 214 homeDirectory: /home/jdoe 215 sshPublicKey: ssh-dss AAAAB3NzaC1kc3MAAAEBAOvL8pREUg9wSy/8+hQJ54YF3AXkB0OZrXB.... 216 [...] 217 --- CUT HERE --- 218 219- LDAP GROUP ENTRY EXAMPLES (LDIF Format, look in groups.ldif) 220 --- CUT HERE --- 221 dn: cn=unix,ou=groups,dc=cuckoos,dc=net 222 objectclass: top 223 objectclass: posixGroup 224 description: Unix based servers group 225 cn: unix 226 gidNumber: 1002 227 memberUid: jdoe 228 memberUid: user1 229 memberUid: user2 230 [...] 231 --- CUT HERE --- 232 233>> FYI: << 234Multiple 'sshPublicKey' in a user entry are allowed, as well as multiple 'memberUid' attributes in a group entry 235 236- COMPILING: 237 1. Apply the patch 238 2. ./configure --with-your-options --with-ldap=/prefix/to/ldap_libs_and_includes 239 3. make 240 4. it's done. 241 242- BLA : 243 I hope this could help, and i hope to be clear enough,, or give ideas. questions/comments/improvements are welcome. 244 245- TODO : 246 Redesign differently. 247 248- DOCS/LINK : 249 http://pacsec.jp/core05/psj05-barisani-en.pdf 250 http://fritz.potsdam.edu/projects/openssh-lpk/ 251 http://fritz.potsdam.edu/projects/sshgate/ 252 http://dev.inversepath.com/trac/openssh-lpk 253 http://lam.sf.net/ ( http://lam.sourceforge.net/documentation/supportedSchemas.htm ) 254 255- CONTRIBUTORS/IDEAS/GREETS : 256 - Falk Siemonsmeier. 257 - Jacob Rief. 258 - Michael Durchgraf. 259 - frederic peters. 260 - Finlay dobbie. 261 - Stefan Fisher. 262 - Robin H. Johnson. 263 - Adrian Bridgett. 264 265- CONTACT : 266 - Eric AUGE <eau@phear.org> 267 - Andrea Barisani <andrea@inversepath.com> 268