Don't forget that ssh-keygen is a real program installed on most computers. ;)
On 18 July 2014 03:13, Jean-Baptiste Onofré <[email protected]> wrote: > Good idea for the password changes before logging. > > And agree for these changes in major releases. That's why I proposed two > steps: the comment of key on next micro release, the "big changes" ;) for > next major one. > > Regards > JB > > > On 07/18/2014 10:10 AM, Guillaume Nodet wrote: > >> Yeahs, it makes sense to me. >> One additional thing about the password that comes to my mind, is the >> ability to integrate the change of password with ssh (when using keyboard >> interactive, the ssh server can ask the user for a password change before >> actually logging in, so that changing the password would also work if >> using >> bin/start and bin/client). >> >> Anyway, those changes are quite important and should be done in minor / >> major releases but maybe not micro ones. >> >> >> 2014-07-18 9:28 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: >> >> Hi Guillaume, >>> >>> I guess you mean default karaf/karaf. >>> >>> Why not doing a kind of "unix" like bootstrap like the root user: we can >>> consider the karaf user as the root user, so mandatory. Why not defining >>> an >>> empty password by default and at bootstrap, if the password is empty >>> (when >>> starting with bin/karaf), prompt for a password. >>> >>> I would propose two steps: >>> - first to "fix" the security hole, comment the key and document how to >>> enable/change it (it will be included in next releases) >>> - second, we provide the ssh:key-gen/key-add and passwd commands/MBeans >>> operations + the prompt of password if the karaf password is empty. >>> >>> WDYT ? >>> >>> Regards >>> JB >>> >>> >>> On 07/18/2014 09:21 AM, Guillaume Nodet wrote: >>> >>> In the same line, shouldn't we remove the default user then ? >>>> And add command or maybe prompt for credentials at first boot ? >>>> >>>> And what about child containers ? Should credentials be propagated >>>> somehow ? >>>> >>>> >>>> 2014-07-17 21:44 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: >>>> >>>> Hi all, >>>> >>>>> >>>>> Following a discussion that we had with Christian, I would like to >>>>> raise >>>>> a >>>>> concern. >>>>> >>>>> Now, on Karaf 2.x/3.x/4.x, the JMX layer is secure using RBAC. The >>>>> MBeanServerBuilder is enabled by default, meaning that it's not >>>>> possible >>>>> to >>>>> locally connect to the MBean server. >>>>> I think it's good and secure. >>>>> >>>>> However, on the other hand, we have a key enabled by default (in >>>>> etc/keys.properties) and used by default by bin/client. >>>>> So it means that any user that download a Karaf distribution can >>>>> connect >>>>> to any Karaf runtimes by default. >>>>> On one hand we have a very secure JMX layer (even for local >>>>> connection), >>>>> but on the other hand, bin/client can connect to any Karaf running >>>>> instance >>>>> (so not very secure). >>>>> >>>>> I would like to propose the following: >>>>> - in etc/keys.properties, we should comment out the default key. We can >>>>> document how to enable it and how to change the keys. >>>>> - in bin/client, we should be able to specify a key that we want to >>>>> use. >>>>> >>>>> WDYT ? >>>>> >>>>> I already created some Jira about the keys: >>>>> - KARAF-2786: I would change this one by comment out the default key >>>>> - KARAF-2836 to allow to specify multiple keys for an user in >>>>> etc/keys.properties >>>>> - KARAF-2787 to allow to specify the key to bin/client >>>>> >>>>> Thanks, >>>>> Regards >>>>> JB >>>>> -- >>>>> Jean-Baptiste Onofré >>>>> [email protected] >>>>> http://blog.nanthrax.net >>>>> Talend - http://www.talend.com >>>>> >>>>> >>>>> >>>> -- >>> Jean-Baptiste Onofré >>> [email protected] >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> >>> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Matt Sicker <[email protected]>
