karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [HEADS UP] Ssh agent and key authentication support
Date Mon, 28 May 2012 12:11:53 GMT
Am 26.05.2012 15:42, schrieb Guillaume Nodet:
> On Sat, May 26, 2012 at 2:41 PM, Christian Schneider
> <chris@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.

+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

> 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<gnodet@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


Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>  Committer & Project

View raw message