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é <[email protected]> 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 >> <[email protected] <mailto:[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 >> >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com >
