Am 26.05.2012 15:42, schrieb Guillaume Nodet: > On Sat, May 26, 2012 at 2:41 PM, Christian Schneider > <[email protected]> wrote: >> As I expressed on IRC I prefer a secure setting by default. If we take a >> look at tomcat then they had the remote management open >> but now have it secure by default and you have to activate it by hand. While >> this is more inconvenient I think it is the only way >> to make sure people don´t leave it open. Karaf is not yet in widespread use >> but if we are succesfull it will be used much more in the future. > As I said, before being widespread, we need Karaf to be easy. When > Karaf will be as popular and known as Tomcat, I think we could revisit > our security strategy.
+1, and to be honest, since we do have a console which is used going to be used by most admins/users where we will prompt some sort of warning we are in a totally different position then tomcat. To achieve something the same with tomcat you need to browse to the starting page of it. > >> I really like the ssh agent as it allows a very convenient management of >> several instances and requires only the little effort of copying the public >> keys >> to the authorized keys file. > I think it's too much. Beginners won't just understand why they can't > connect to the karaf instance, have to find some documentation, do the > manipulation. It may take 20 minutes, and people that just want to > give it a try may very well not try that. > >> So the question is if having a default private key is the only option to >> achieve a convenient management. I think we have other options that are >> almost as convenient and >> pose no security risk. >> >> - One option is to log the public keys on the server instance and provide a >> command to allow them to connect (add them to the authorized keys) >> - Another option is to provide a command to create a remote instance using >> the ssh access to the remote system (similar to fuse fabric). After creating >> the instance we could allow to also copy keys. So the instance could be >> reached without a password. >> - For local access using the client command we could create a private key in >> the user dir and add it to the authorized keys at first start of karaf. So >> the client >> command would work without a password and still be secure. >> >> One good thing about these options is that they also apply to production >> instances while the default private key would never be an option there. > What you want is a centralized user management system. That's a good > thing to have, I just don't think Karaf has to provide it. That > could be a subproject, but I'm quite sure there are already good > solutions for that. I always thought I'm able to achieve this with JAAS, just plugin the centralized user management available. Like ActiveDirectory / LDAP or what ever one would like. > > And I don't think this proposal is good at production time. People > will want to know the key before deployment so that it can be used to > actually access the instance. Having to start the instance, wait > until the key is generated so that you can later be able to log in > does not sound like something very easy. Also any solution that would > involve securing the private key would have to also secure the default > password in the same way. +1, yep I do favor KISS also, and this proposal doesn't sound like KISS. > >> Christian >> >> >> >> Am 25.05.2012 18:34, schrieb Guillaume Nodet: >>> So Christian has expressed concerns with the current state: >>> >>> "Currently we create a private key at build time and allow full >>> access with this key by default. I think this opens a big security >>> hole. Of course the same is true for the karaf:karaf user. What makes >>> the private key more dangerous is that people might not see this hole >>> as easily as the default user. So I think we should not do this. >>> Instead I propose to create a key at runtime and use it to connect to >>> the local instance. We could store the generated private key in the >>> user dir to make sure it is at a safe place." >>> >>> We had a chat on IRC so I'll try to summarize my thinking as well. >>> >>> The current state uses a static private key. The main idea was to be >>> able in development mode, to easily access remote instances without >>> any additional configurations. The private key is used by the console >>> (when karaf is started with bin/karaf) and also by the bin/client for >>> default authentication. >>> To disable that (which is obviously bad when putting karaf in >>> production, as I explained in an earlier mail), one has to disable the >>> line in etc/keys.properties and etc/users.properties. >>> This is similar to what we had with the default login / password and >>> hardcoded password in ssh:ssh and bin/client, so I don't really see >>> that as a real problem. >>> >>> I propose to add a warning to the console and log when starting karaf >>> with such a default key enabled (i.e. the default key is available to >>> log in) instead, so that we could keep the ability to easily connect >>> to any instance at development time without additional configuration. >>> >>> Thoughts welcomed. >>> >>> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<[email protected]> wrote: >>>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport >>>> it to trunk next week). >>>> This changes the way the ssh authentication default mechanism works to >>>> leverage ssh agent forwarding and key based authentication. >>>> In short, the default ssh and admin:connect command don't use the >>>> karaf/karaf login/password authentication by default, but use the ssh >>>> agent instead. >>>> The default console uses an internal key which is accepted by adding >>>> the public part in etc/authorized_keys and a local ssh agent which >>>> will be used by default when using ssh / admin:connect command. >>>> When connecting from the outside, one should use the ssh agent >>>> forwarding on the client (ssh -l 8101 -A localhost), and that will >>>> allow you to automatically connect to other karaf instances if the key >>>> is supported too. >>>> Basically, what this means is that the usual default (i.e. you don't >>>> have to specify the password anyway) should work in a real environment >>>> where the default password / key has been changed. >>>> >>>> One thing I just realized I forgot is to enhance the bin/client script >>>> to also use the same private key by default. >>>> Another thing I found (and need to fix), is that the public key >>>> authentication mechanism does not really check the association between >>>> the key used and the user: i.e. any username can be used with any >>>> known key, which is quite bad. Possible enhancements also include a >>>> way to change the "default" key which is used when starting a usual >>>> karaf ; however, given I don't think that's much used in real >>>> production environment, I think this is quite minor and kinda force >>>> the user to use karaf the "right" way. The first step before putting >>>> karaf in prod would be to disallow the default public key and start >>>> karaf using bin/start instead of bin/karaf. >>>> >>>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd. >>>> >>>> I'll fix some of the above things next week, and I then plan to start >>>> working on role based authentication on the shell somehow (one thing >>>> we can imagine is a su/sudo mode or something similar). I really >>>> can't bear the confirmation that are prompted any time you want to do >>>> something with bundles anymore, so I think it's time for something >>>> more powerful and flexible. >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> FuseSource, Integration everywhere >>>> http://fusesource.com >>> >>> >> >> -- >> >> Christian Schneider >> http://www.liquid-reality.de >> >> Open Source Architect >> Talend Application Integration Division http://www.talend.com >> > > -- ----- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
