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 Fri, 25 May 2012 22:00:13 GMT
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<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
>
>


-- 
- 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/>


Mime
View raw message