Hi Guillaume,
I'm fine with the way it is, and I think a documentation warning
together with a warning in the console is sufficient enough.
Since it's possible to color the input we should put a nice "nasty"
coloring to this warning that'll catch attention.
regards, Achim
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
--
- Apache Karaf<http://karaf.apache.org/> Committer& PMC
- OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer&
Project Lead
- Blog<http://notizblog.nierbeck.de/>
