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