Karaf can only generate a private key for the user which is actually running karaf, not for others. The reason is that private keys need to be only readable by the user, and only the user (or an admin) could do that. Also, I really don't think Karaf should mess with the ssh setting of the OS at all.
If we want to integrate with the OS, that is doable (but that's a different problem) using PAM. SSHD has a sshd-pam module which I started a while ago, but didn't really finished for lack of a good java pam library with java. And also because I doubt people would really want to use that in production (I have never seen such a requirement yet). It could also be done using Kerberos, but that's not something which should be enabled by default. I don't think we should make things more complicated than they are. The security mechanism of Karaf rely on JAAS, so it's really pluggable. The default implementation provided by Karaf should be simple enough that it can support being secured and easily manageable. I don't think it should be tied to the OS or even try to be the best security system. There are very good products that already do that and that's not really Karaf goal, it should just be able to integrate with those using LDAP for example (so I guess at some point, we need an LDAP login module for key based authentication). One thing I really focus on is ease of use. At dev time, we want Karaf to be the easiest to use as possible. So that people can actually download karaf, try and experiment without being bugged by too many things to do and understand to be able to try things. Having a secured security system by default would also be a problem when writing system tests that use multiple instances too. At prod time, we want Karaf to be easily secured. Changing the etc/users.properties and etc/keys.properties to secure Karaf really seem a good compromise to me, in conjunction with a big red warning when Karaf is started in dev mode. Christian, even if Tomcat changed its default security to be more secured, I don't think we should do the same. Karaf is (by far) not as popular as Tomcat, and Tomcat does not have the same need as Karaf, i.e. be able to propagate security tokens from an instance to another. And if we want Karaf to become popular, once again, we need to be the easiest to use, which means, you should start it and it should just work. On Sat, May 26, 2012 at 2:22 PM, Christian Schneider <[email protected]> wrote: > It is unix specific but on that platform it really might make sense to use > the user keys and hosts. > As we need a safe place for at least the private keys I think it makes sense > to use the user dir for them. > So we could just use the directory structure that ssh uses. > > On windows these directories would not be there but we could still use the > same structure. > > Christian > > Am 25.05.2012 22:03, schrieb Guillaume Nodet: > >> That's unix specific and we have windows users ... >> >> On Fri, May 25, 2012 at 9:13 PM, Ioannis Canellos<[email protected]> >> wrote: >>> >>> I may lost some bits, but couldn't we just reuse the users keys and >>> authorized hosts, instead of creating, adding or removing? >>> >>> -- >>> *Ioannis Canellos* >>> * >>> FuseSource<http://fusesource.com> >>> >>> ** >>> Blog: http://iocanel.blogspot.com >>> ** >>> Twitter: iocanel >>> * >> >> >> > > > -- > > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
