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 <[email protected]> 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 <[email protected]> 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 <
>> [email protected]> 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
>>>
>>
>>
>

Reply via email to