You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Elliot Huntington <el...@gmail.com> on 2016/07/05 22:49:27 UTC
How to secure Karaf
I wrote a question (
http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
on stack overflow pertaining to Christian Schneider's blog post, How to
hack into any default apache karaf installation
<http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation>.
After following his instructions to secure the container the `bin/client`
command, rather than failing, appears to create a new file `etc/host.key`
and successfully connects to the container. This was unexpected according
to the blog post.
It would be helpful if someone would answer this question on stack overflow.
Thanks,
Elliot
Re: How to secure Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I forgot:
0. if provided use key auth ;)
Regards
JB
On 07/06/2016 09:23 PM, Jean-Baptiste Onofr� wrote:
> By default bin/client tries (in this order):
> 1. to read etc/users.properties when possible
> 2. to use karaf/karaf
> 3. to use -u and prompt for the password
>
> bin/client is a SSH client (written in Java). The host.key is the same
> file as for SSH and containing the trusted hosts (you also have
> .sshkaraf/known_hosts for that).
>
> Regards
> JB
>
> On 07/06/2016 08:50 PM, Elliot Huntington wrote:
>> This makes sense. So, I gather from this explanation that the container
>> is secure (in as much as the default password has been changed and the
>> default private key has been deleted) but the bin/client command will
>> still use whatever password is specified in the etc/users.properties
>> file? If so, this would explain why on 4.0.5 bin/client was able to
>> successfully log into the container without having to explicitly specify
>> a password. But if this is true, then I'm still curious: what is the
>> purpose of the etc/host.key file that is created by the container (or
>> maybe the bin/client command) if the etc/keys.properties file is
>> missing? What is the point of that file if the bin/client command is
>> using the password specified in etc/users.properties to connect to the
>> container?
>>
>> On Wed, Jul 6, 2016 at 12:43 PM, Jean-Baptiste Onofr� <jb@nanthrax.net
>> <ma...@nanthrax.net>> wrote:
>>
>> Previously, bin/client embedded a default key (as you can see in
>> etc/keys.properties). It's now disable.
>>
>> However, bin/client assumes username karaf and password karaf,
>> that's why you don't have to provide anything.
>>
>> You can change the default password in etc/users.properties.
>>
>> Regards
>> JB
>>
>> On 07/06/2016 01:16 AM, Kevin Schmidt wrote:
>>
>> I just followed the instructions to secure the container and
>> using
>> bin/client does now require a password and doesn't successfully
>> connect
>> to the container. I did this with Karaf 3.0.6. Perhaps
>> something
>> changed with Karaf 4?
>>
>> Kevin
>>
>> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington
>> <elliot.huntington@gmail.com
>> <ma...@gmail.com>
>> <mailto:elliot.huntington@gmail.com
>> <ma...@gmail.com>>> wrote:
>>
>> I wrote a question
>>
>>
>> (http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
>>
>> on stack overflow pertaining to Christian Schneider's blog
>> post, How
>> to hack into any default apache karaf installation
>>
>>
>> <http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation>.
>>
>> After following his instructions to secure the container the
>> `bin/client` command, rather than failing, appears to
>> create a new
>> file `etc/host.key` and successfully connects to the
>> container. This
>> was unexpected according to the blog post.
>>
>> It would be helpful if someone would answer this question
>> on stack
>> overflow.
>>
>> Thanks,
>> Elliot
>>
>>
>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: How to secure Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
By default bin/client tries (in this order):
1. to read etc/users.properties when possible
2. to use karaf/karaf
3. to use -u and prompt for the password
bin/client is a SSH client (written in Java). The host.key is the same
file as for SSH and containing the trusted hosts (you also have
.sshkaraf/known_hosts for that).
Regards
JB
On 07/06/2016 08:50 PM, Elliot Huntington wrote:
> This makes sense. So, I gather from this explanation that the container
> is secure (in as much as the default password has been changed and the
> default private key has been deleted) but the bin/client command will
> still use whatever password is specified in the etc/users.properties
> file? If so, this would explain why on 4.0.5 bin/client was able to
> successfully log into the container without having to explicitly specify
> a password. But if this is true, then I'm still curious: what is the
> purpose of the etc/host.key file that is created by the container (or
> maybe the bin/client command) if the etc/keys.properties file is
> missing? What is the point of that file if the bin/client command is
> using the password specified in etc/users.properties to connect to the
> container?
>
> On Wed, Jul 6, 2016 at 12:43 PM, Jean-Baptiste Onofr� <jb@nanthrax.net
> <ma...@nanthrax.net>> wrote:
>
> Previously, bin/client embedded a default key (as you can see in
> etc/keys.properties). It's now disable.
>
> However, bin/client assumes username karaf and password karaf,
> that's why you don't have to provide anything.
>
> You can change the default password in etc/users.properties.
>
> Regards
> JB
>
> On 07/06/2016 01:16 AM, Kevin Schmidt wrote:
>
> I just followed the instructions to secure the container and using
> bin/client does now require a password and doesn't successfully
> connect
> to the container. I did this with Karaf 3.0.6. Perhaps something
> changed with Karaf 4?
>
> Kevin
>
> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington
> <elliot.huntington@gmail.com
> <ma...@gmail.com>
> <mailto:elliot.huntington@gmail.com
> <ma...@gmail.com>>> wrote:
>
> I wrote a question
>
> (http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
> on stack overflow pertaining to Christian Schneider's blog
> post, How
> to hack into any default apache karaf installation
>
> <http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation>.
> After following his instructions to secure the container the
> `bin/client` command, rather than failing, appears to
> create a new
> file `etc/host.key` and successfully connects to the
> container. This
> was unexpected according to the blog post.
>
> It would be helpful if someone would answer this question
> on stack
> overflow.
>
> Thanks,
> Elliot
>
>
>
> --
> Jean-Baptiste Onofr�
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: How to secure Karaf
Posted by Elliot Huntington <el...@gmail.com>.
This makes sense. So, I gather from this explanation that the container is
secure (in as much as the default password has been changed and the default
private key has been deleted) but the bin/client command will still use
whatever password is specified in the etc/users.properties file? If so,
this would explain why on 4.0.5 bin/client was able to successfully log
into the container without having to explicitly specify a password. But if
this is true, then I'm still curious: what is the purpose of the
etc/host.key file that is created by the container (or maybe the bin/client
command) if the etc/keys.properties file is missing? What is the point of
that file if the bin/client command is using the password specified in
etc/users.properties to connect to the container?
On Wed, Jul 6, 2016 at 12:43 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> Previously, bin/client embedded a default key (as you can see in
> etc/keys.properties). It's now disable.
>
> However, bin/client assumes username karaf and password karaf, that's why
> you don't have to provide anything.
>
> You can change the default password in etc/users.properties.
>
> Regards
> JB
>
> On 07/06/2016 01:16 AM, Kevin Schmidt wrote:
>
>> I just followed the instructions to secure the container and using
>> bin/client does now require a password and doesn't successfully connect
>> to the container. I did this with Karaf 3.0.6. Perhaps something
>> changed with Karaf 4?
>>
>> Kevin
>>
>> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington
>> <elliot.huntington@gmail.com <ma...@gmail.com>> wrote:
>>
>> I wrote a question
>> (
>> http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation
>> )
>> on stack overflow pertaining to Christian Schneider's blog post, How
>> to hack into any default apache karaf installation
>> <
>> http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation
>> >.
>> After following his instructions to secure the container the
>> `bin/client` command, rather than failing, appears to create a new
>> file `etc/host.key` and successfully connects to the container. This
>> was unexpected according to the blog post.
>>
>> It would be helpful if someone would answer this question on stack
>> overflow.
>>
>> Thanks,
>> Elliot
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: How to secure Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Previously, bin/client embedded a default key (as you can see in
etc/keys.properties). It's now disable.
However, bin/client assumes username karaf and password karaf, that's
why you don't have to provide anything.
You can change the default password in etc/users.properties.
Regards
JB
On 07/06/2016 01:16 AM, Kevin Schmidt wrote:
> I just followed the instructions to secure the container and using
> bin/client does now require a password and doesn't successfully connect
> to the container. I did this with Karaf 3.0.6. Perhaps something
> changed with Karaf 4?
>
> Kevin
>
> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington
> <elliot.huntington@gmail.com <ma...@gmail.com>> wrote:
>
> I wrote a question
> (http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
> on stack overflow pertaining to Christian Schneider's blog post, How
> to hack into any default apache karaf installation
> <http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation>.
> After following his instructions to secure the container the
> `bin/client` command, rather than failing, appears to create a new
> file `etc/host.key` and successfully connects to the container. This
> was unexpected according to the blog post.
>
> It would be helpful if someone would answer this question on stack
> overflow.
>
> Thanks,
> Elliot
>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: How to secure Karaf
Posted by Kevin Schmidt <kt...@gmail.com>.
I have not tried with 4.0.5 but will try to.
And didn't mean to hi-jack the thread, but it appears bin/client does have
a -k command line option to specify a different file with the private key
that should work.
On Wed, Jul 6, 2016 at 11:29 AM, Elliot Huntington <
elliot.huntington@gmail.com> wrote:
> I appreciate Kevin's follow up question and am eager to know the answer to
> it myself. But I hope this separate question does not hijack this thread.
> I'm still looking for an answer to my stack overflow question.
>
> Kevin, are you able to reproduce securing the container with version
> 4.0.5. I'm going to test this with 3.0.6 to see if I get the same results
> you got.
>
> On Wed, Jul 6, 2016 at 9:56 AM, Kevin Schmidt <kt...@gmail.com> wrote:
>
>> I have a follow up question.
>>
>> It is good that one can disable this feature, but if someone would like
>> to use this feature of bin/client to connect without a password but do so
>> with their own public/private key pair, how would bin/client be told to use
>> it? Is that possible or is the private key built in to
>> org.apache.karaf.client.Main?
>>
>> On Tue, Jul 5, 2016 at 4:16 PM, Kevin Schmidt <kt...@gmail.com>
>> wrote:
>>
>>> I just followed the instructions to secure the container and using
>>> bin/client does now require a password and doesn't successfully connect to
>>> the container. I did this with Karaf 3.0.6. Perhaps something changed
>>> with Karaf 4?
>>>
>>> Kevin
>>>
>>> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington <
>>> elliot.huntington@gmail.com> wrote:
>>>
>>>> I wrote a question (
>>>> http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
>>>> on stack overflow pertaining to Christian Schneider's blog post, How
>>>> to hack into any default apache karaf installation
>>>> <http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation>.
>>>> After following his instructions to secure the container the `bin/client`
>>>> command, rather than failing, appears to create a new file `etc/host.key`
>>>> and successfully connects to the container. This was unexpected according
>>>> to the blog post.
>>>>
>>>> It would be helpful if someone would answer this question on stack
>>>> overflow.
>>>>
>>>> Thanks,
>>>> Elliot
>>>>
>>>
>>>
>>
>
Re: How to secure Karaf
Posted by Elliot Huntington <el...@gmail.com>.
I appreciate Kevin's follow up question and am eager to know the answer to
it myself. But I hope this separate question does not hijack this thread.
I'm still looking for an answer to my stack overflow question.
Kevin, are you able to reproduce securing the container with version 4.0.5.
I'm going to test this with 3.0.6 to see if I get the same results you got.
On Wed, Jul 6, 2016 at 9:56 AM, Kevin Schmidt <kt...@gmail.com> wrote:
> I have a follow up question.
>
> It is good that one can disable this feature, but if someone would like to
> use this feature of bin/client to connect without a password but do so with
> their own public/private key pair, how would bin/client be told to use it?
> Is that possible or is the private key built in to
> org.apache.karaf.client.Main?
>
> On Tue, Jul 5, 2016 at 4:16 PM, Kevin Schmidt <kt...@gmail.com> wrote:
>
>> I just followed the instructions to secure the container and using
>> bin/client does now require a password and doesn't successfully connect to
>> the container. I did this with Karaf 3.0.6. Perhaps something changed
>> with Karaf 4?
>>
>> Kevin
>>
>> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington <
>> elliot.huntington@gmail.com> wrote:
>>
>>> I wrote a question (
>>> http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
>>> on stack overflow pertaining to Christian Schneider's blog post, How to
>>> hack into any default apache karaf installation
>>> <http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation>.
>>> After following his instructions to secure the container the `bin/client`
>>> command, rather than failing, appears to create a new file `etc/host.key`
>>> and successfully connects to the container. This was unexpected according
>>> to the blog post.
>>>
>>> It would be helpful if someone would answer this question on stack
>>> overflow.
>>>
>>> Thanks,
>>> Elliot
>>>
>>
>>
>
Re: How to secure Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Kevin,
you have to use the -k option:
-k [keyFile] specify the private keyFile location when using key
login, need have BouncyCastle registered as security provider using this
flag
On the Karaf side, you need bouncycastle provider and populate the
etc/keys.properties.
It's documented there:
http://karaf.apache.org/manual/latest/#_managing_authentication_by_key
Regards
JB
On 07/06/2016 05:56 PM, Kevin Schmidt wrote:
> I have a follow up question.
>
> It is good that one can disable this feature, but if someone would like
> to use this feature of bin/client to connect without a password but do
> so with their own public/private key pair, how would bin/client be told
> to use it? Is that possible or is the private key built in to
> org.apache.karaf.client.Main?
>
> On Tue, Jul 5, 2016 at 4:16 PM, Kevin Schmidt <ktschmidt@gmail.com
> <ma...@gmail.com>> wrote:
>
> I just followed the instructions to secure the container and using
> bin/client does now require a password and doesn't successfully
> connect to the container. I did this with Karaf 3.0.6. Perhaps
> something changed with Karaf 4?
>
> Kevin
>
> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington
> <elliot.huntington@gmail.com <ma...@gmail.com>>
> wrote:
>
> I wrote a question
> (http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
> on stack overflow pertaining to Christian Schneider's blog post,
> How to hack into any default apache karaf installation
> <http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation>.
> After following his instructions to secure the container the
> `bin/client` command, rather than failing, appears to create a
> new file `etc/host.key` and successfully connects to the
> container. This was unexpected according to the blog post.
>
> It would be helpful if someone would answer this question on
> stack overflow.
>
> Thanks,
> Elliot
>
>
>
--
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: How to secure Karaf
Posted by Kevin Schmidt <kt...@gmail.com>.
I have a follow up question.
It is good that one can disable this feature, but if someone would like to
use this feature of bin/client to connect without a password but do so with
their own public/private key pair, how would bin/client be told to use it?
Is that possible or is the private key built in to
org.apache.karaf.client.Main?
On Tue, Jul 5, 2016 at 4:16 PM, Kevin Schmidt <kt...@gmail.com> wrote:
> I just followed the instructions to secure the container and using
> bin/client does now require a password and doesn't successfully connect to
> the container. I did this with Karaf 3.0.6. Perhaps something changed
> with Karaf 4?
>
> Kevin
>
> On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington <
> elliot.huntington@gmail.com> wrote:
>
>> I wrote a question (
>> http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
>> on stack overflow pertaining to Christian Schneider's blog post, How to
>> hack into any default apache karaf installation
>> <http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation>.
>> After following his instructions to secure the container the `bin/client`
>> command, rather than failing, appears to create a new file `etc/host.key`
>> and successfully connects to the container. This was unexpected according
>> to the blog post.
>>
>> It would be helpful if someone would answer this question on stack
>> overflow.
>>
>> Thanks,
>> Elliot
>>
>
>
Re: How to secure Karaf
Posted by Kevin Schmidt <kt...@gmail.com>.
I just followed the instructions to secure the container and using
bin/client does now require a password and doesn't successfully connect to
the container. I did this with Karaf 3.0.6. Perhaps something changed
with Karaf 4?
Kevin
On Tue, Jul 5, 2016 at 3:49 PM, Elliot Huntington <
elliot.huntington@gmail.com> wrote:
> I wrote a question (
> http://stackoverflow.com/questions/38176918/how-to-secure-the-default-apache-karaf-installation)
> on stack overflow pertaining to Christian Schneider's blog post, How to
> hack into any default apache karaf installation
> <http://www.liquid-reality.de/display/liquid/2014/01/08/How+to+hack+into+any+default+apache+karaf+installation>.
> After following his instructions to secure the container the `bin/client`
> command, rather than failing, appears to create a new file `etc/host.key`
> and successfully connects to the container. This was unexpected according
> to the blog post.
>
> It would be helpful if someone would answer this question on stack
> overflow.
>
> Thanks,
> Elliot
>