On Sat, May 26, 2012 at 2:41 PM, Christian Schneider <ch...@die-schneider.net> 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. > > 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. 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. > > 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<gno...@gmail.com> 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 > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
