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