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 -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
