For management of larger sites is useful to use distributed authorized private keys. This patch allows use the agent to obtaining the keys. There are possibility of use popen (agent) instead of open (authorized_keys). The feature is triggered a new configure option. The two sshd_config options configure the agent run string and the user account used for running the agent. It's accepted that the agent output is the same as the file format of authorized_keys2 file. Local authorized_key files are skipped in the case of the active agent. Only the protocol 2 is supported actually.
Created attachment 1703 [details] Patch solving the problem
Created attachment 1765 [details] newer version of the patch newer version of the patch, repaired the PubkeyAgentRunAs parameter parsing.
This is an interesting idea. My concerns are: 1) you lose the ability to specify key restrictions. I.e. you can't force commands on a per-key basis, disable port-forwarding, etc. 2) I think it would be better if you don't run the agent from sshd. Instead, you add a single directive to sshd_config to inform it of an agent socket path and use ssh-agent's "-a" option to make it listen on a single location. 3) ssh-agent has not be written with robustness against deliberately malformed input in mind and will fatal() at the first encoding error. This is good behaviour for a per-user agent, but could lead to system-level DoS when used to manage public keys for a host. We should probably discuss this on the mailing list.
(In reply to comment #3) > This is an interesting idea. My concerns are: > this is not necessary limited to LPK compatibility, even the transport protocol, may be different. > 1) you lose the ability to specify key restrictions. I.e. you can't > force commands on a per-key basis, disable port-forwarding, etc. > the keys are transported as is with all the prefixes (forced commands &tc..) > 2) I think it would be better if you don't run the agent from sshd. > Instead, you add a single directive to sshd_config to inform it of an > agent socket path and use ssh-agent's "-a" option to make it listen on > a single location. > a) The per session fork may be useful, when the executed process should be run under the authorized user privileges. b) The fork-execute at each autentization have some advantages and some disadvantages. The advantages are: better stability - killing the process does not cause the DoS. Less vulnerability for memory leaks. The process finishes with all non freed memory after each authentization. The disadvantages: more process and more sockets used. > 3) ssh-agent has not be written with robustness against deliberately > malformed input in mind and will fatal() at the first encoding error. > This is good behaviour for a per-user agent, but could lead to > system-level DoS when used to manage public keys for a host. > > We should probably discuss this on the mailing list.
Created attachment 1804 [details] patch against openssh5.4p1
Created attachment 1811 [details] pattch against openssh-5.4p1
This seems like an excellent way to provide the same functionality as the LPK patch. It is also more generic and allows people to write their own implementations for storing public keys in ldap, oracle, or whatever. This seems like the best way to get people to stop asking for lpk to be added to sshd.
(In reply to comment #7) > This seems like an excellent way to provide the same functionality as > the LPK patch. > The LDAP backend is prepared and now is in the testing stage. I hope to post it here in a week or less. > It is also more generic and allows people to write their own > implementations for storing public keys in ldap, oracle, or whatever. > > This seems like the best way to get people to stop asking for lpk to be > added to sshd. Yes, yes, yes. It still needs some minor improvements, but from the security point of view it's ready.
Created attachment 1850 [details] Full patch containing LDAP part
Can anybody test the patch in other than linux environment? All comments are welcomed.
*** Bug 1778 has been marked as a duplicate of this bug. ***
I've tested the patch on Fedora Linux - so not a different system environment unfortunately - but I can confirm it works well there. I agree this is proper way how to replace the lpk patch. I don't even think that the LDAP backend part has to be included in the openssh upstream sources, this can be very well distributed separately along with other possible backends.
Created attachment 1895 [details] updated pubkey-agent patch against 5.5p1 (with security fixes) The Monkeysphere development team is interested in seeing this modular key-based authorization functionality included in OpenSSH. We believe the LDAP-specific code should be distributed separately. We reviewed the pubkey-agent patch today, and found a handful of problems that appear to need fixing. The attached patch applies against 5.5p1, and resolves the immediate problems. The concerns we found were: 0) not all components of the path to the command were checked for proper ownership and permissions. 1) using popen() while under temporarily_use_uid() meant that a child process could re-elevate its privileges to root with seteuid(). 2) the combination of strtok, percent expansion, and the implicit sh -c invocation (via popen()) leave open a number of possibilities to violate the principle of least surprise for an unfortunate sysadmin. Our revised patch resolves (1) by explicitly fork()ing and exec()ing, permanently dropping privileges in the child process before the exec(). Our revised patch resolves (2) by requiring the command be a single explicit path to an executable, which will receive a single command-line argument (the name of the user to authorize). We also felt that the earlier patch was mistaken by invalidating the AuthorizedKeysFile option if PubkeyAgent is present. The admin is already able to disable AuthorizedKeysFile (e.g. by pointing it to /dev/null). Also, having a (new, relatively-unknown) option have potentially surprising interactions with another (well-known, widely-understood) option seems like a bad idea. Our approach was to provide fall-through behavior. If the PubkeyAgent does not authorize the connecting key, sshd will consult AuthorizedKeysFile as in current versions of OpenSSH. Note that we also feel the choice of option names leaves something to be desired. PubkeyAgent and PubkeyAgentRunAs are misleading, since there is no required agent at all. The term AuthorizedKeysCommand (see #1778) seems more appropriate by analogy with existing config options LocalCommand, ProxyCommand and AuthorizedKeysFile. I'll offer a revised patch with the updated names shortly.
Created attachment 1896 [details] patch using AuthorizedKeysCommand terminology Here is the patch using the sshd_config options AuthorizedKeysCommand and AuthorizedKeysCommandRunAs. The ./configure option is --with-authorized-keys-command. This seems preferable to the PubkeyAgent terminology.
Created attachment 1915 [details] Patch suitable for openssh-5.6p1
Created attachment 1920 [details] Patch suitable for openssh-5.6p1
It's been year now how can we get someone from the team to evaluate this for mainline development or just close down the idea. This is a significant feature with a flexible solution to the needs of many and it's hard to believe that it has not seemed worthy for inclusion in the main openssh dev. Maybe redhat could start including this in their package builds since one of the devs is keeping a patch with this. As a fortune50 user of RHEL it would greatly increase my security if I could turn off password login across my environment except for a few bastille hosts and keep user public keys in LDAP.
This feature is included in last releases of Fedora and RHEL6 products.
Created attachment 2067 [details] Patch suitable for OpenSSH 5.8p2 Added patch suitable for OpenSSH 5.8p2
What is the reason that this patch is not yet included in the release? And it is not yet scheduled for 6.0?
Created attachment 2083 [details] patch for openssh-5.9p1
> Created attachment 1850 [details] > Full patch containing LDAP part Thx for that Patch, but it won´t build. gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wno-pointer-sign -Wformat-security -fno-strict-aliasing -fno-builtin-memset -fstack-protector-all -I. -I. -DWITH_LDAP_PUBKEY -DSSHDIR=\"/etc/ssh\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/local/libexec/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -c ldapconf.c ldapconf.c: In function âprocess_config_lineâ: ldapconf.c:204: error: âLDAP_SCOPE_SUBTREEâ undeclared (first use in this function) ldapconf.c:204: error: (Each undeclared identifier is reported only once ldapconf.c:204: error: for each function it appears in.) ldapconf.c:206: error: âLDAP_SCOPE_ONELEVELâ undeclared (first use in this function) ldapconf.c:208: error: âLDAP_SCOPE_BASEâ undeclared (first use in this function) ldapconf.c:222: error: âLDAP_DEREF_NEVERâ undeclared (first use in this function) ldapconf.c:224: error: âLDAP_DEREF_SEARCHINGâ undeclared (first use in this function) ldapconf.c:226: error: âLDAP_DEREF_FINDINGâ undeclared (first use in this function) ldapconf.c:228: error: âLDAP_DEREF_ALWAYSâ undeclared (first use in this function) ldapconf.c:339: error: âLDAP_OPT_X_TLS_NEVERâ undeclared (first use in this function) ldapconf.c:341: error: âLDAP_OPT_X_TLS_HARDâ undeclared (first use in this function) ldapconf.c:343: error: âLDAP_OPT_X_TLS_DEMANDâ undeclared (first use in this function) ldapconf.c:345: error: âLDAP_OPT_X_TLS_ALLOWâ undeclared (first use in this function) ldapconf.c:347: error: âLDAP_OPT_X_TLS_TRYâ undeclared (first use in this function) ldapconf.c: In function âfill_default_optionsâ: ldapconf.c:503: error: âLDAPURLDescâ undeclared (first use in this function) ldapconf.c:503: error: âludpâ undeclared (first use in this function) ldapconf.c:505: warning: implicit declaration of function âldap_url_parseâ ldapconf.c:505: error: âLDAP_SUCCESSâ undeclared (first use in this function) ldapconf.c:507: warning: left-hand operand of comma expression has no effect ldapconf.c:507: warning: value computed is not used ldapconf.c:507: warning: left-hand operand of comma expression has no effect ldapconf.c:509: warning: left-hand operand of comma expression has no effect ldapconf.c:509: warning: value computed is not used ldapconf.c:509: warning: left-hand operand of comma expression has no effect ldapconf.c:511: warning: left-hand operand of comma expression has no effect ldapconf.c:511: warning: value computed is not used ldapconf.c:511: warning: left-hand operand of comma expression has no effect ldapconf.c:519: warning: implicit declaration of function âldap_free_urldescâ ldapconf.c:541: error: âLDAP_SCOPE_SUBTREEâ undeclared (first use in this function) ldapconf.c:543: error: âLDAP_DEREF_NEVERâ undeclared (first use in this function) ldapconf.c:557: error: âLDAP_OPT_X_TLS_HARDâ undeclared (first use in this function) ldapconf.c: At top level: ldapconf.c:622: error: âLDAP_SCOPE_BASEâ undeclared here (not in a function) ldapconf.c:623: error: âLDAP_SCOPE_ONELEVELâ undeclared here (not in a function) ldapconf.c:624: error: âLDAP_SCOPE_SUBTREEâ undeclared here (not in a function) ldapconf.c:628: error: âLDAP_DEREF_NEVERâ undeclared here (not in a function) ldapconf.c:628: error: initializer element is not constant ldapconf.c:628: error: (near initialization for â_deref[0].valueâ) ldapconf.c:629: error: âLDAP_DEREF_SEARCHINGâ undeclared here (not in a function) ldapconf.c:629: error: initializer element is not constant ldapconf.c:629: error: (near initialization for â_deref[1].valueâ) ldapconf.c:630: error: âLDAP_DEREF_FINDINGâ undeclared here (not in a function) ldapconf.c:630: error: initializer element is not constant ldapconf.c:630: error: (near initialization for â_deref[2].valueâ) ldapconf.c:631: error: âLDAP_DEREF_ALWAYSâ undeclared here (not in a function) ldapconf.c:631: error: initializer element is not constant ldapconf.c:631: error: (near initialization for â_deref[3].valueâ) ldapconf.c:645: error: âLDAP_OPT_X_TLS_NEVERâ undeclared here (not in a function) ldapconf.c:645: error: initializer element is not constant ldapconf.c:645: error: (near initialization for â_checkpeer[0].valueâ) ldapconf.c:646: error: âLDAP_OPT_X_TLS_HARDâ undeclared here (not in a function) ldapconf.c:646: error: initializer element is not constant ldapconf.c:646: error: (near initialization for â_checkpeer[1].valueâ) ldapconf.c:647: error: âLDAP_OPT_X_TLS_DEMANDâ undeclared here (not in a function) ldapconf.c:647: error: initializer element is not constant ldapconf.c:647: error: (near initialization for â_checkpeer[2].valueâ) ldapconf.c:648: error: âLDAP_OPT_X_TLS_ALLOWâ undeclared here (not in a function) ldapconf.c:648: error: initializer element is not constant ldapconf.c:648: error: (near initialization for â_checkpeer[3].valueâ) ldapconf.c:649: error: âLDAP_OPT_X_TLS_TRYâ undeclared here (not in a function) ldapconf.c:649: error: initializer element is not constant ldapconf.c:649: error: (near initialization for â_checkpeer[4].valueâ) make: *** [ldapconf.o] Error 1 What can i do ?
(In reply to comment #22) > > Created attachment 1850 [details] > > Full patch containing LDAP part > > Thx for that Patch, but it won´t build. You don't mention which version of OpenSSH you tried to compile the LDAP patch against. > What can i do ? You could try using the AuthorizedKeysCommand variant, which is simpler and more up-to-date with the current version of OpenSSH.
(In reply to comment #23) > You don't mention which version of OpenSSH you tried to compile the > LDAP patch against. Hi, sorry, i used openssh5.5p1 for this patch. > You could try using the AuthorizedKeysCommand variant, which is simpler > and more up-to-date with the current version of OpenSSH. Can you me explain, how it works with ldap, and which settings to use ? BR
(In reply to comment #24) > Can you me explain, how it works with ldap, and which settings to use ? perhaps jchadima@redhat.com can suggest something? I don't do much work with LDAP here.
(In reply to comment #25) > perhaps jchadima@redhat.com can suggest something? I don't do much > work with LDAP here. <jchadima@redhat.com>: host xxxx[xxxx] said: 550 5.2.1 <jchadima@redhat.com>... Mailbox disabled for this recipient (in reply to RCPT TO command) ;( I hope he will read here.
In the Fedora openssh rpm package you should find some documentation on the AuthorizedKeysCommand helper for the keys in LDAP.
The LDAP backend is now done as the patch to openssh build in Fedora. This is not the best way how this should be done. If you are brave enough, you could change it in a standalone project. Everything is ready in the patch, only the Makefile and configure or cmake should be prepared. If you are able to do it, do it please.
(I'm sorry I have to do this) A bump for the bug. It has been 2.4 years since the original patch... and please, close or accept this.
Another ping. I really could use this patch for a network of dynamically provisioned hosts.
Created attachment 2191 [details] Revised patch, against -current as of 20121005 Here is a cleaned up version of the patch that I have out for review at the moment. If you are using a previous patch then you should switch to this one as it fixes a few bugs, at least one with substantial security consequences under some configurations.
Patch applied. This will be in OpenSSH 6.2, most likely early next year.
mark bugs closed by openssh-6.2 release as CLOSED
For those curious, I've posted some ideas for extending that mechanism in bug #2981. Cheers, Chris.
I'm pretty sure Christoph means bug 2081
Indeed,.. sorry for the wrong copy&paste :)