You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Guillaume Nodet <gn...@gmail.com> on 2012/05/18 13:56:48 UTC
[HEADS UP] Ssh agent and key authentication support
I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
it to trunk next week).
This changes the way the ssh authentication default mechanism works to
leverage ssh agent forwarding and key based authentication.
In short, the default ssh and admin:connect command don't use the
karaf/karaf login/password authentication by default, but use the ssh
agent instead.
The default console uses an internal key which is accepted by adding
the public part in etc/authorized_keys and a local ssh agent which
will be used by default when using ssh / admin:connect command.
When connecting from the outside, one should use the ssh agent
forwarding on the client (ssh -l 8101 -A localhost), and that will
allow you to automatically connect to other karaf instances if the key
is supported too.
Basically, what this means is that the usual default (i.e. you don't
have to specify the password anyway) should work in a real environment
where the default password / key has been changed.
One thing I just realized I forgot is to enhance the bin/client script
to also use the same private key by default.
Another thing I found (and need to fix), is that the public key
authentication mechanism does not really check the association between
the key used and the user: i.e. any username can be used with any
known key, which is quite bad. Possible enhancements also include a
way to change the "default" key which is used when starting a usual
karaf ; however, given I don't think that's much used in real
production environment, I think this is quite minor and kinda force
the user to use karaf the "right" way. The first step before putting
karaf in prod would be to disallow the default public key and start
karaf using bin/start instead of bin/karaf.
Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
I'll fix some of the above things next week, and I then plan to start
working on role based authentication on the shell somehow (one thing
we can imagine is a su/sudo mode or something similar). I really
can't bear the confirmation that are prompted any time you want to do
something with bundles anymore, so I think it's time for something
more powerful and flexible.
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Christian Schneider <ch...@die-schneider.net>.
I am also focusing on ease of use and you are right ease of use is a key
enabler for success of Karaf.
So how about having the default private key but having it disabled by
default.
For example we could have a hash before the key in the keys.properties
or have a switch in config.properties that is turned off by default.
So it is really easy to enable the feature but still the default is secure.
About the integration with the OS ssh I am also not sure if it is good
or not. In some cases it may be wanted in others not.
Christian
Am 26.05.2012 15:32, schrieb Guillaume Nodet:
> Karaf can only generate a private key for the user which is actually
> running karaf, not for others. The reason is that private keys need
> to be only readable by the user, and only the user (or an admin) could
> do that. Also, I really don't think Karaf should mess with the ssh
> setting of the OS at all.
>
> If we want to integrate with the OS, that is doable (but that's a
> different problem) using PAM. SSHD has a sshd-pam module which I
> started a while ago, but didn't really finished for lack of a good
> java pam library with java. And also because I doubt people would
> really want to use that in production (I have never seen such a
> requirement yet). It could also be done using Kerberos, but that's
> not something which should be enabled by default.
>
> I don't think we should make things more complicated than they are.
> The security mechanism of Karaf rely on JAAS, so it's really
> pluggable. The default implementation provided by Karaf should be
> simple enough that it can support being secured and easily manageable.
> I don't think it should be tied to the OS or even try to be the best
> security system. There are very good products that already do that
> and that's not really Karaf goal, it should just be able to integrate
> with those using LDAP for example (so I guess at some point, we need
> an LDAP login module for key based authentication).
>
> One thing I really focus on is ease of use. At dev time, we want
> Karaf to be the easiest to use as possible. So that people can
> actually download karaf, try and experiment without being bugged by
> too many things to do and understand to be able to try things. Having
> a secured security system by default would also be a problem when
> writing system tests that use multiple instances too.
> At prod time, we want Karaf to be easily secured. Changing the
> etc/users.properties and etc/keys.properties to secure Karaf really
> seem a good compromise to me, in conjunction with a big red warning
> when Karaf is started in dev mode.
>
> Christian, even if Tomcat changed its default security to be more
> secured, I don't think we should do the same. Karaf is (by far) not
> as popular as Tomcat, and Tomcat does not have the same need as Karaf,
> i.e. be able to propagate security tokens from an instance to another.
> And if we want Karaf to become popular, once again, we need to be the
> easiest to use, which means, you should start it and it should just
> work.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Guillaume Nodet <gn...@gmail.com>.
Karaf can only generate a private key for the user which is actually
running karaf, not for others. The reason is that private keys need
to be only readable by the user, and only the user (or an admin) could
do that. Also, I really don't think Karaf should mess with the ssh
setting of the OS at all.
If we want to integrate with the OS, that is doable (but that's a
different problem) using PAM. SSHD has a sshd-pam module which I
started a while ago, but didn't really finished for lack of a good
java pam library with java. And also because I doubt people would
really want to use that in production (I have never seen such a
requirement yet). It could also be done using Kerberos, but that's
not something which should be enabled by default.
I don't think we should make things more complicated than they are.
The security mechanism of Karaf rely on JAAS, so it's really
pluggable. The default implementation provided by Karaf should be
simple enough that it can support being secured and easily manageable.
I don't think it should be tied to the OS or even try to be the best
security system. There are very good products that already do that
and that's not really Karaf goal, it should just be able to integrate
with those using LDAP for example (so I guess at some point, we need
an LDAP login module for key based authentication).
One thing I really focus on is ease of use. At dev time, we want
Karaf to be the easiest to use as possible. So that people can
actually download karaf, try and experiment without being bugged by
too many things to do and understand to be able to try things. Having
a secured security system by default would also be a problem when
writing system tests that use multiple instances too.
At prod time, we want Karaf to be easily secured. Changing the
etc/users.properties and etc/keys.properties to secure Karaf really
seem a good compromise to me, in conjunction with a big red warning
when Karaf is started in dev mode.
Christian, even if Tomcat changed its default security to be more
secured, I don't think we should do the same. Karaf is (by far) not
as popular as Tomcat, and Tomcat does not have the same need as Karaf,
i.e. be able to propagate security tokens from an instance to another.
And if we want Karaf to become popular, once again, we need to be the
easiest to use, which means, you should start it and it should just
work.
On Sat, May 26, 2012 at 2:22 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> It is unix specific but on that platform it really might make sense to use
> the user keys and hosts.
> As we need a safe place for at least the private keys I think it makes sense
> to use the user dir for them.
> So we could just use the directory structure that ssh uses.
>
> On windows these directories would not be there but we could still use the
> same structure.
>
> Christian
>
> Am 25.05.2012 22:03, schrieb Guillaume Nodet:
>
>> That's unix specific and we have windows users ...
>>
>> On Fri, May 25, 2012 at 9:13 PM, Ioannis Canellos<io...@gmail.com>
>> wrote:
>>>
>>> I may lost some bits, but couldn't we just reuse the users keys and
>>> authorized hosts, instead of creating, adding or removing?
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>> FuseSource<http://fusesource.com>
>>>
>>> **
>>> Blog: http://iocanel.blogspot.com
>>> **
>>> Twitter: iocanel
>>> *
>>
>>
>>
>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Christian Schneider <ch...@die-schneider.net>.
It is unix specific but on that platform it really might make sense to
use the user keys and hosts.
As we need a safe place for at least the private keys I think it makes
sense to use the user dir for them.
So we could just use the directory structure that ssh uses.
On windows these directories would not be there but we could still use
the same structure.
Christian
Am 25.05.2012 22:03, schrieb Guillaume Nodet:
> That's unix specific and we have windows users ...
>
> On Fri, May 25, 2012 at 9:13 PM, Ioannis Canellos<io...@gmail.com> wrote:
>> I may lost some bits, but couldn't we just reuse the users keys and
>> authorized hosts, instead of creating, adding or removing?
>>
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource<http://fusesource.com>
>>
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Twitter: iocanel
>> *
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Guillaume Nodet <gn...@gmail.com>.
That's unix specific and we have windows users ...
On Fri, May 25, 2012 at 9:13 PM, Ioannis Canellos <io...@gmail.com> wrote:
> I may lost some bits, but couldn't we just reuse the users keys and
> authorized hosts, instead of creating, adding or removing?
>
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Twitter: iocanel
> *
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Ioannis Canellos <io...@gmail.com>.
I may lost some bits, but couldn't we just reuse the users keys and
authorized hosts, instead of creating, adding or removing?
--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Christian Schneider <ch...@die-schneider.net>.
Of course we can try to secure access to the file system but this is a
really difficult task and can cause a lot of side effects.
After all it will always be necessary to let karaf admins install
bundles and some of these bundle need access to the file system.
I think blocking access on the outer layer like ssh is the easier solution.
Christian
Am 29.05.2012 13:07, schrieb Guillaume Nodet:
> That's a fair and valid point. I think this needs to be given some thoughts.
> The problem in that case isn't really to secure karaf itself, but
> rather the OS file system, which can be used as a gateway to access
> the file system and execute commands.
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Guillaume Nodet <gn...@gmail.com>.
That's a fair and valid point. I think this needs to be given some thoughts.
The problem in that case isn't really to secure karaf itself, but
rather the OS file system, which can be used as a gateway to access
the file system and execute commands.
On Tue, May 29, 2012 at 11:13 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> If the majority of dev here is ok with a warning I go with it but let me
> explain some scenarios that make me concerned.
> First as Guillaume noted already we have to treat the default user
> karaf/karaf in the same way as the default private key.
>
> So the argument for a default of an open access to karaf is that it will
> just be used on dev machines and is no problem there. So lets examine what a
> developer
> has access to and uses from its machine:
>
> - Company Mail account, private Mail account
> - File shares of the company. Often very sensitive informations
> - Often access to the HR system of the company with sensitive information
> like salary
> - Access to online banking
> - Many devs are also admins. So they access production systems. Often devs
> have a file with encrypted passwords that they access with a master password
>
> So these are resources that I think should be protected well.
>
> So what are the risks when running karaf in the default open mode?
>
> - An attacker can access the karaf instance remotely (only has to have IP
> access to the machine)
> - He can install code from remote sources and run it with the users
> priviledges that karaf runs in. Typically this user is the dev user which in
> many cases is also local system admin
> - He can read and write all files in reach of that user. Among these are the
> encrypted passwords mentioned above
> - He can install a keylogger and get access to other systems the dev logs
> into. This way he will also get the master password for the encrypted
> passwords
> - He can install software to use the microphone and camera of the machine
>
> So the question is: Do you trust everyone in the local network?
>
> If no then why should it be a good default to have karaf wide open by
> default?
>
> Christian
>
>
> Am 28.05.2012 14:11, schrieb Achim Nierbeck:
>
>> +1, and to be honest, since we do have a console which is used going to
>> be used by most
>> admins/users where we will prompt some sort of warning we are in a
>> totally different
>> position then tomcat. To achieve something the same with tomcat you need
>> to browse
>> to the starting page of it.
>>
>>>> I really like the ssh agent as it allows a very convenient management of
>>>> several instances and requires only the little effort of copying the
>>>> public
>>>> keys
>>>> to the authorized keys file.
>>>
>>> I think it's too much. Beginners won't just understand why they can't
>>> connect to the karaf instance, have to find some documentation, do the
>>> manipulation. It may take 20 minutes, and people that just want to
>>> give it a try may very well not try that.
>>>
>>>> So the question is if having a default private key is the only option to
>>>> achieve a convenient management. I think we have other options that are
>>>> almost as convenient and
>>>> pose no security risk.
>>>>
>>>> - One option is to log the public keys on the server instance and
>>>> provide a
>>>> command to allow them to connect (add them to the authorized keys)
>>>> - Another option is to provide a command to create a remote instance
>>>> using
>>>> the ssh access to the remote system (similar to fuse fabric). After
>>>> creating
>>>> the instance we could allow to also copy keys. So the instance could be
>>>> reached without a password.
>>>> - For local access using the client command we could create a private
>>>> key in
>>>> the user dir and add it to the authorized keys at first start of karaf.
>>>> So
>>>> the client
>>>> command would work without a password and still be secure.
>>>>
>>>> One good thing about these options is that they also apply to production
>>>> instances while the default private key would never be an option there.
>>>
>>> What you want is a centralized user management system. That's a good
>>> thing to have, I just don't think Karaf has to provide it. That
>>> could be a subproject, but I'm quite sure there are already good
>>> solutions for that.
>>
>> I always thought I'm able to achieve this with JAAS, just plugin the
>> centralized user
>> management available. Like ActiveDirectory / LDAP or what ever one would
>> like.
>>
>>> And I don't think this proposal is good at production time. People
>>> will want to know the key before deployment so that it can be used to
>>> actually access the instance. Having to start the instance, wait
>>> until the key is generated so that you can later be able to log in
>>> does not sound like something very easy. Also any solution that would
>>> involve securing the private key would have to also secure the default
>>> password in the same way.
>>
>> +1, yep I do favor KISS also, and this proposal doesn't sound like KISS.
>>
>>>> Christian
>>>>
>>>>
>>>>
>>>> Am 25.05.2012 18:34, schrieb Guillaume Nodet:
>>>>>
>>>>> So Christian has expressed concerns with the current state:
>>>>>
>>>>> "Currently we create a private key at build time and allow full
>>>>> access with this key by default. I think this opens a big security
>>>>> hole. Of course the same is true for the karaf:karaf user. What makes
>>>>> the private key more dangerous is that people might not see this hole
>>>>> as easily as the default user. So I think we should not do this.
>>>>> Instead I propose to create a key at runtime and use it to connect to
>>>>> the local instance. We could store the generated private key in the
>>>>> user dir to make sure it is at a safe place."
>>>>>
>>>>> We had a chat on IRC so I'll try to summarize my thinking as well.
>>>>>
>>>>> The current state uses a static private key. The main idea was to be
>>>>> able in development mode, to easily access remote instances without
>>>>> any additional configurations. The private key is used by the console
>>>>> (when karaf is started with bin/karaf) and also by the bin/client for
>>>>> default authentication.
>>>>> To disable that (which is obviously bad when putting karaf in
>>>>> production, as I explained in an earlier mail), one has to disable the
>>>>> line in etc/keys.properties and etc/users.properties.
>>>>> This is similar to what we had with the default login / password and
>>>>> hardcoded password in ssh:ssh and bin/client, so I don't really see
>>>>> that as a real problem.
>>>>>
>>>>> I propose to add a warning to the console and log when starting karaf
>>>>> with such a default key enabled (i.e. the default key is available to
>>>>> log in) instead, so that we could keep the ability to easily connect
>>>>> to any instance at development time without additional configuration.
>>>>>
>>>>> Thoughts welcomed.
>>>>>
>>>>> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gn...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
>>>>>> it to trunk next week).
>>>>>> This changes the way the ssh authentication default mechanism works to
>>>>>> leverage ssh agent forwarding and key based authentication.
>>>>>> In short, the default ssh and admin:connect command don't use the
>>>>>> karaf/karaf login/password authentication by default, but use the ssh
>>>>>> agent instead.
>>>>>> The default console uses an internal key which is accepted by adding
>>>>>> the public part in etc/authorized_keys and a local ssh agent which
>>>>>> will be used by default when using ssh / admin:connect command.
>>>>>> When connecting from the outside, one should use the ssh agent
>>>>>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>>>>>> allow you to automatically connect to other karaf instances if the key
>>>>>> is supported too.
>>>>>> Basically, what this means is that the usual default (i.e. you don't
>>>>>> have to specify the password anyway) should work in a real environment
>>>>>> where the default password / key has been changed.
>>>>>>
>>>>>> One thing I just realized I forgot is to enhance the bin/client script
>>>>>> to also use the same private key by default.
>>>>>> Another thing I found (and need to fix), is that the public key
>>>>>> authentication mechanism does not really check the association between
>>>>>> the key used and the user: i.e. any username can be used with any
>>>>>> known key, which is quite bad. Possible enhancements also include a
>>>>>> way to change the "default" key which is used when starting a usual
>>>>>> karaf ; however, given I don't think that's much used in real
>>>>>> production environment, I think this is quite minor and kinda force
>>>>>> the user to use karaf the "right" way. The first step before putting
>>>>>> karaf in prod would be to disallow the default public key and start
>>>>>> karaf using bin/start instead of bin/karaf.
>>>>>>
>>>>>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>>>>>
>>>>>> I'll fix some of the above things next week, and I then plan to start
>>>>>> working on role based authentication on the shell somehow (one thing
>>>>>> we can imagine is a su/sudo mode or something similar). I really
>>>>>> can't bear the confirmation that are prompted any time you want to do
>>>>>> something with bundles anymore, so I think it's time for something
>>>>>> more powerful and flexible.
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> FuseSource, Integration everywhere
>>>>>> http://fusesource.com
>>>>>
>>>>>
>>>> --
>>>>
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> Talend Application Integration Division http://www.talend.com
>>>>
>>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Achim Nierbeck <bc...@googlemail.com>.
I doubt that there will be some sort of Virus specialized for Karaf.
The day we have to focus on this is the day we made it ;)
So we should keep the balances here. And right now I don't see that there
is a real need to complicate the way it works right now.
A proper warning is merely enough to catch a real admins attention.
regards, Achim
2012/5/29 Christian Schneider <ch...@die-schneider.net>:
> Of course viruses are also able to attack the resources I described but a
> virus needs a vulnerability or some help of the user to spread.
> An open karaf is one of those vulnerabilities.
>
> Christian
>
> Am 29.05.2012 14:10, schrieb Achim Nierbeck:
>
>> Hi Christian,
>>
>> my comments inline :)
>>
>> regards, Achim
>>
>> 2012/5/29 Christian Schneider<ch...@die-schneider.net>:
>>>
>>> If the majority of dev here is ok with a warning I go with it but let me
>>> explain some scenarios that make me concerned.
>>> First as Guillaume noted already we have to treat the default user
>>> karaf/karaf in the same way as the default private key.
>>>
>>> So the argument for a default of an open access to karaf is that it will
>>> just be used on dev machines and is no problem there. So lets examine
>>> what a
>>> developer
>>> has access to and uses from its machine:
>>>
>>> - Company Mail account, private Mail account
>>
>> fair enough, though I don't see the threat of opening another door
>> here, there are plenty of viruses out there (especially for windows,
>> that'll find their way to this)
>>
>>> - File shares of the company. Often very sensitive informations
>>
>> I'm unsure about the sensitive inormation, I'm quite sure companies will
>> make sure only certain groups of people have access to parts of the
>> data or all.
>>
>>> - Often access to the HR system of the company with sensitive information
>>> like salary
>>
>> Nope, I don't see this threat.
>>
>>> - Access to online banking
>>
>> Any dev that does use his company PC for this but not his private is
>> doing this in his own responsibility.
>> I don't consider this to be a major threat.
>>
>>> - Many devs are also admins. So they access production systems. Often
>>> devs
>>> have a file with encrypted passwords that they access with a master
>>> password
>>
>> this threat is not more or less then whit std. viruses
>>
>>> So these are resources that I think should be protected well.
>>>
>>> So what are the risks when running karaf in the default open mode?
>>>
>>> - An attacker can access the karaf instance remotely (only has to have IP
>>> access to the machine)
>>
>> that's what firewalls are for, and you have those open doors with
>> internal structures already
>> so no real new threat here.
>>
>>> - He can install code from remote sources and run it with the users
>>> priviledges that karaf runs in. Typically this user is the dev user which
>>> in
>>> many cases is also local system admin
>>
>> again, firewalls protect internal structures from external attacks.
>> Internal Attacks are
>> as usual the main issue, and you don't need an Karaf to expose extra
>> threats.
>>
>>> - He can read and write all files in reach of that user. Among these are
>>> the
>>> encrypted passwords mentioned above
>>
>> see above
>>
>>> - He can install a keylogger and get access to other systems the dev logs
>>> into. This way he will also get the master password for the encrypted
>>> passwords
>>
>> see above
>>
>>> - He can install software to use the microphone and camera of the machine
>>
>> it's called "Flame" I think ...
>>
>>> So the question is: Do you trust everyone in the local network?
>>>
>>> If no then why should it be a good default to have karaf wide open by
>>> default?
>>
>> I think most of your ideas concerning the threats are there but do not
>> depent on
>> Karaf but mostly on internal infrastructure. So this is an issue for the
>> admins
>> of the company. I don't think Karaf exposes new threats.
>>
>>> Christian
>>>
>>>
>>> Am 28.05.2012 14:11, schrieb Achim Nierbeck:
>>>
>>>> +1, and to be honest, since we do have a console which is used going to
>>>> be used by most
>>>> admins/users where we will prompt some sort of warning we are in a
>>>> totally different
>>>> position then tomcat. To achieve something the same with tomcat you need
>>>> to browse
>>>> to the starting page of it.
>>>>
>>>>>> I really like the ssh agent as it allows a very convenient management
>>>>>> of
>>>>>> several instances and requires only the little effort of copying the
>>>>>> public
>>>>>> keys
>>>>>> to the authorized keys file.
>>>>>
>>>>> I think it's too much. Beginners won't just understand why they can't
>>>>> connect to the karaf instance, have to find some documentation, do the
>>>>> manipulation. It may take 20 minutes, and people that just want to
>>>>> give it a try may very well not try that.
>>>>>
>>>>>> So the question is if having a default private key is the only option
>>>>>> to
>>>>>> achieve a convenient management. I think we have other options that
>>>>>> are
>>>>>> almost as convenient and
>>>>>> pose no security risk.
>>>>>>
>>>>>> - One option is to log the public keys on the server instance and
>>>>>> provide a
>>>>>> command to allow them to connect (add them to the authorized keys)
>>>>>> - Another option is to provide a command to create a remote instance
>>>>>> using
>>>>>> the ssh access to the remote system (similar to fuse fabric). After
>>>>>> creating
>>>>>> the instance we could allow to also copy keys. So the instance could
>>>>>> be
>>>>>> reached without a password.
>>>>>> - For local access using the client command we could create a private
>>>>>> key in
>>>>>> the user dir and add it to the authorized keys at first start of
>>>>>> karaf.
>>>>>> So
>>>>>> the client
>>>>>> command would work without a password and still be secure.
>>>>>>
>>>>>> One good thing about these options is that they also apply to
>>>>>> production
>>>>>> instances while the default private key would never be an option
>>>>>> there.
>>>>>
>>>>> What you want is a centralized user management system. That's a good
>>>>> thing to have, I just don't think Karaf has to provide it. That
>>>>> could be a subproject, but I'm quite sure there are already good
>>>>> solutions for that.
>>>>
>>>> I always thought I'm able to achieve this with JAAS, just plugin the
>>>> centralized user
>>>> management available. Like ActiveDirectory / LDAP or what ever one would
>>>> like.
>>>>
>>>>> And I don't think this proposal is good at production time. People
>>>>> will want to know the key before deployment so that it can be used to
>>>>> actually access the instance. Having to start the instance, wait
>>>>> until the key is generated so that you can later be able to log in
>>>>> does not sound like something very easy. Also any solution that would
>>>>> involve securing the private key would have to also secure the default
>>>>> password in the same way.
>>>>
>>>> +1, yep I do favor KISS also, and this proposal doesn't sound like KISS.
>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 25.05.2012 18:34, schrieb Guillaume Nodet:
>>>>>>>
>>>>>>> So Christian has expressed concerns with the current state:
>>>>>>>
>>>>>>> "Currently we create a private key at build time and allow full
>>>>>>> access with this key by default. I think this opens a big security
>>>>>>> hole. Of course the same is true for the karaf:karaf user. What makes
>>>>>>> the private key more dangerous is that people might not see this hole
>>>>>>> as easily as the default user. So I think we should not do this.
>>>>>>> Instead I propose to create a key at runtime and use it to connect to
>>>>>>> the local instance. We could store the generated private key in the
>>>>>>> user dir to make sure it is at a safe place."
>>>>>>>
>>>>>>> We had a chat on IRC so I'll try to summarize my thinking as well.
>>>>>>>
>>>>>>> The current state uses a static private key. The main idea was to be
>>>>>>> able in development mode, to easily access remote instances without
>>>>>>> any additional configurations. The private key is used by the
>>>>>>> console
>>>>>>> (when karaf is started with bin/karaf) and also by the bin/client for
>>>>>>> default authentication.
>>>>>>> To disable that (which is obviously bad when putting karaf in
>>>>>>> production, as I explained in an earlier mail), one has to disable
>>>>>>> the
>>>>>>> line in etc/keys.properties and etc/users.properties.
>>>>>>> This is similar to what we had with the default login / password and
>>>>>>> hardcoded password in ssh:ssh and bin/client, so I don't really see
>>>>>>> that as a real problem.
>>>>>>>
>>>>>>> I propose to add a warning to the console and log when starting karaf
>>>>>>> with such a default key enabled (i.e. the default key is available to
>>>>>>> log in) instead, so that we could keep the ability to easily connect
>>>>>>> to any instance at development time without additional configuration.
>>>>>>>
>>>>>>> Thoughts welcomed.
>>>>>>>
>>>>>>> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll
>>>>>>>> backport
>>>>>>>> it to trunk next week).
>>>>>>>> This changes the way the ssh authentication default mechanism works
>>>>>>>> to
>>>>>>>> leverage ssh agent forwarding and key based authentication.
>>>>>>>> In short, the default ssh and admin:connect command don't use the
>>>>>>>> karaf/karaf login/password authentication by default, but use the
>>>>>>>> ssh
>>>>>>>> agent instead.
>>>>>>>> The default console uses an internal key which is accepted by adding
>>>>>>>> the public part in etc/authorized_keys and a local ssh agent which
>>>>>>>> will be used by default when using ssh / admin:connect command.
>>>>>>>> When connecting from the outside, one should use the ssh agent
>>>>>>>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>>>>>>>> allow you to automatically connect to other karaf instances if the
>>>>>>>> key
>>>>>>>> is supported too.
>>>>>>>> Basically, what this means is that the usual default (i.e. you don't
>>>>>>>> have to specify the password anyway) should work in a real
>>>>>>>> environment
>>>>>>>> where the default password / key has been changed.
>>>>>>>>
>>>>>>>> One thing I just realized I forgot is to enhance the bin/client
>>>>>>>> script
>>>>>>>> to also use the same private key by default.
>>>>>>>> Another thing I found (and need to fix), is that the public key
>>>>>>>> authentication mechanism does not really check the association
>>>>>>>> between
>>>>>>>> the key used and the user: i.e. any username can be used with any
>>>>>>>> known key, which is quite bad. Possible enhancements also include a
>>>>>>>> way to change the "default" key which is used when starting a usual
>>>>>>>> karaf ; however, given I don't think that's much used in real
>>>>>>>> production environment, I think this is quite minor and kinda force
>>>>>>>> the user to use karaf the "right" way. The first step before
>>>>>>>> putting
>>>>>>>> karaf in prod would be to disallow the default public key and start
>>>>>>>> karaf using bin/start instead of bin/karaf.
>>>>>>>>
>>>>>>>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>>>>>>>
>>>>>>>> I'll fix some of the above things next week, and I then plan to
>>>>>>>> start
>>>>>>>> working on role based authentication on the shell somehow (one thing
>>>>>>>> we can imagine is a su/sudo mode or something similar). I really
>>>>>>>> can't bear the confirmation that are prompted any time you want to
>>>>>>>> do
>>>>>>>> something with bundles anymore, so I think it's time for something
>>>>>>>> more powerful and flexible.
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> FuseSource, Integration everywhere
>>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>>
>>>>>> Christian Schneider
>>>>>> http://www.liquid-reality.de
>>>>>>
>>>>>> Open Source Architect
>>>>>> Talend Application Integration Division http://www.talend.com
>>>>>>
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Christian Schneider <ch...@die-schneider.net>.
Of course viruses are also able to attack the resources I described but
a virus needs a vulnerability or some help of the user to spread.
An open karaf is one of those vulnerabilities.
Christian
Am 29.05.2012 14:10, schrieb Achim Nierbeck:
> Hi Christian,
>
> my comments inline :)
>
> regards, Achim
>
> 2012/5/29 Christian Schneider<ch...@die-schneider.net>:
>> If the majority of dev here is ok with a warning I go with it but let me
>> explain some scenarios that make me concerned.
>> First as Guillaume noted already we have to treat the default user
>> karaf/karaf in the same way as the default private key.
>>
>> So the argument for a default of an open access to karaf is that it will
>> just be used on dev machines and is no problem there. So lets examine what a
>> developer
>> has access to and uses from its machine:
>>
>> - Company Mail account, private Mail account
> fair enough, though I don't see the threat of opening another door
> here, there are plenty of viruses out there (especially for windows,
> that'll find their way to this)
>
>> - File shares of the company. Often very sensitive informations
> I'm unsure about the sensitive inormation, I'm quite sure companies will
> make sure only certain groups of people have access to parts of the
> data or all.
>
>> - Often access to the HR system of the company with sensitive information
>> like salary
> Nope, I don't see this threat.
>
>> - Access to online banking
> Any dev that does use his company PC for this but not his private is
> doing this in his own responsibility.
> I don't consider this to be a major threat.
>
>> - Many devs are also admins. So they access production systems. Often devs
>> have a file with encrypted passwords that they access with a master password
> this threat is not more or less then whit std. viruses
>
>> So these are resources that I think should be protected well.
>>
>> So what are the risks when running karaf in the default open mode?
>>
>> - An attacker can access the karaf instance remotely (only has to have IP
>> access to the machine)
> that's what firewalls are for, and you have those open doors with
> internal structures already
> so no real new threat here.
>
>> - He can install code from remote sources and run it with the users
>> priviledges that karaf runs in. Typically this user is the dev user which in
>> many cases is also local system admin
> again, firewalls protect internal structures from external attacks.
> Internal Attacks are
> as usual the main issue, and you don't need an Karaf to expose extra threats.
>
>> - He can read and write all files in reach of that user. Among these are the
>> encrypted passwords mentioned above
> see above
>
>> - He can install a keylogger and get access to other systems the dev logs
>> into. This way he will also get the master password for the encrypted
>> passwords
> see above
>
>> - He can install software to use the microphone and camera of the machine
> it's called "Flame" I think ...
>
>> So the question is: Do you trust everyone in the local network?
>>
>> If no then why should it be a good default to have karaf wide open by
>> default?
> I think most of your ideas concerning the threats are there but do not
> depent on
> Karaf but mostly on internal infrastructure. So this is an issue for the admins
> of the company. I don't think Karaf exposes new threats.
>
>> Christian
>>
>>
>> Am 28.05.2012 14:11, schrieb Achim Nierbeck:
>>
>>> +1, and to be honest, since we do have a console which is used going to
>>> be used by most
>>> admins/users where we will prompt some sort of warning we are in a
>>> totally different
>>> position then tomcat. To achieve something the same with tomcat you need
>>> to browse
>>> to the starting page of it.
>>>
>>>>> I really like the ssh agent as it allows a very convenient management of
>>>>> several instances and requires only the little effort of copying the
>>>>> public
>>>>> keys
>>>>> to the authorized keys file.
>>>> I think it's too much. Beginners won't just understand why they can't
>>>> connect to the karaf instance, have to find some documentation, do the
>>>> manipulation. It may take 20 minutes, and people that just want to
>>>> give it a try may very well not try that.
>>>>
>>>>> So the question is if having a default private key is the only option to
>>>>> achieve a convenient management. I think we have other options that are
>>>>> almost as convenient and
>>>>> pose no security risk.
>>>>>
>>>>> - One option is to log the public keys on the server instance and
>>>>> provide a
>>>>> command to allow them to connect (add them to the authorized keys)
>>>>> - Another option is to provide a command to create a remote instance
>>>>> using
>>>>> the ssh access to the remote system (similar to fuse fabric). After
>>>>> creating
>>>>> the instance we could allow to also copy keys. So the instance could be
>>>>> reached without a password.
>>>>> - For local access using the client command we could create a private
>>>>> key in
>>>>> the user dir and add it to the authorized keys at first start of karaf.
>>>>> So
>>>>> the client
>>>>> command would work without a password and still be secure.
>>>>>
>>>>> One good thing about these options is that they also apply to production
>>>>> instances while the default private key would never be an option there.
>>>> What you want is a centralized user management system. That's a good
>>>> thing to have, I just don't think Karaf has to provide it. That
>>>> could be a subproject, but I'm quite sure there are already good
>>>> solutions for that.
>>> I always thought I'm able to achieve this with JAAS, just plugin the
>>> centralized user
>>> management available. Like ActiveDirectory / LDAP or what ever one would
>>> like.
>>>
>>>> And I don't think this proposal is good at production time. People
>>>> will want to know the key before deployment so that it can be used to
>>>> actually access the instance. Having to start the instance, wait
>>>> until the key is generated so that you can later be able to log in
>>>> does not sound like something very easy. Also any solution that would
>>>> involve securing the private key would have to also secure the default
>>>> password in the same way.
>>> +1, yep I do favor KISS also, and this proposal doesn't sound like KISS.
>>>
>>>>> Christian
>>>>>
>>>>>
>>>>>
>>>>> Am 25.05.2012 18:34, schrieb Guillaume Nodet:
>>>>>> So Christian has expressed concerns with the current state:
>>>>>>
>>>>>> "Currently we create a private key at build time and allow full
>>>>>> access with this key by default. I think this opens a big security
>>>>>> hole. Of course the same is true for the karaf:karaf user. What makes
>>>>>> the private key more dangerous is that people might not see this hole
>>>>>> as easily as the default user. So I think we should not do this.
>>>>>> Instead I propose to create a key at runtime and use it to connect to
>>>>>> the local instance. We could store the generated private key in the
>>>>>> user dir to make sure it is at a safe place."
>>>>>>
>>>>>> We had a chat on IRC so I'll try to summarize my thinking as well.
>>>>>>
>>>>>> The current state uses a static private key. The main idea was to be
>>>>>> able in development mode, to easily access remote instances without
>>>>>> any additional configurations. The private key is used by the console
>>>>>> (when karaf is started with bin/karaf) and also by the bin/client for
>>>>>> default authentication.
>>>>>> To disable that (which is obviously bad when putting karaf in
>>>>>> production, as I explained in an earlier mail), one has to disable the
>>>>>> line in etc/keys.properties and etc/users.properties.
>>>>>> This is similar to what we had with the default login / password and
>>>>>> hardcoded password in ssh:ssh and bin/client, so I don't really see
>>>>>> that as a real problem.
>>>>>>
>>>>>> I propose to add a warning to the console and log when starting karaf
>>>>>> with such a default key enabled (i.e. the default key is available to
>>>>>> log in) instead, so that we could keep the ability to easily connect
>>>>>> to any instance at development time without additional configuration.
>>>>>>
>>>>>> Thoughts welcomed.
>>>>>>
>>>>>> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gn...@gmail.com>
>>>>>> wrote:
>>>>>>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
>>>>>>> it to trunk next week).
>>>>>>> This changes the way the ssh authentication default mechanism works to
>>>>>>> leverage ssh agent forwarding and key based authentication.
>>>>>>> In short, the default ssh and admin:connect command don't use the
>>>>>>> karaf/karaf login/password authentication by default, but use the ssh
>>>>>>> agent instead.
>>>>>>> The default console uses an internal key which is accepted by adding
>>>>>>> the public part in etc/authorized_keys and a local ssh agent which
>>>>>>> will be used by default when using ssh / admin:connect command.
>>>>>>> When connecting from the outside, one should use the ssh agent
>>>>>>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>>>>>>> allow you to automatically connect to other karaf instances if the key
>>>>>>> is supported too.
>>>>>>> Basically, what this means is that the usual default (i.e. you don't
>>>>>>> have to specify the password anyway) should work in a real environment
>>>>>>> where the default password / key has been changed.
>>>>>>>
>>>>>>> One thing I just realized I forgot is to enhance the bin/client script
>>>>>>> to also use the same private key by default.
>>>>>>> Another thing I found (and need to fix), is that the public key
>>>>>>> authentication mechanism does not really check the association between
>>>>>>> the key used and the user: i.e. any username can be used with any
>>>>>>> known key, which is quite bad. Possible enhancements also include a
>>>>>>> way to change the "default" key which is used when starting a usual
>>>>>>> karaf ; however, given I don't think that's much used in real
>>>>>>> production environment, I think this is quite minor and kinda force
>>>>>>> the user to use karaf the "right" way. The first step before putting
>>>>>>> karaf in prod would be to disallow the default public key and start
>>>>>>> karaf using bin/start instead of bin/karaf.
>>>>>>>
>>>>>>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>>>>>>
>>>>>>> I'll fix some of the above things next week, and I then plan to start
>>>>>>> working on role based authentication on the shell somehow (one thing
>>>>>>> we can imagine is a su/sudo mode or something similar). I really
>>>>>>> can't bear the confirmation that are prompted any time you want to do
>>>>>>> something with bundles anymore, so I think it's time for something
>>>>>>> more powerful and flexible.
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> FuseSource, Integration everywhere
>>>>>>> http://fusesource.com
>>>>>>
>>>>> --
>>>>>
>>>>> Christian Schneider
>>>>> http://www.liquid-reality.de
>>>>>
>>>>> Open Source Architect
>>>>> Talend Application Integration Division http://www.talend.com
>>>>>
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Christian,
my comments inline :)
regards, Achim
2012/5/29 Christian Schneider <ch...@die-schneider.net>:
> If the majority of dev here is ok with a warning I go with it but let me
> explain some scenarios that make me concerned.
> First as Guillaume noted already we have to treat the default user
> karaf/karaf in the same way as the default private key.
>
> So the argument for a default of an open access to karaf is that it will
> just be used on dev machines and is no problem there. So lets examine what a
> developer
> has access to and uses from its machine:
>
> - Company Mail account, private Mail account
fair enough, though I don't see the threat of opening another door
here, there are plenty of viruses out there (especially for windows,
that'll find their way to this)
> - File shares of the company. Often very sensitive informations
I'm unsure about the sensitive inormation, I'm quite sure companies will
make sure only certain groups of people have access to parts of the
data or all.
> - Often access to the HR system of the company with sensitive information
> like salary
Nope, I don't see this threat.
> - Access to online banking
Any dev that does use his company PC for this but not his private is
doing this in his own responsibility.
I don't consider this to be a major threat.
> - Many devs are also admins. So they access production systems. Often devs
> have a file with encrypted passwords that they access with a master password
this threat is not more or less then whit std. viruses
>
> So these are resources that I think should be protected well.
>
> So what are the risks when running karaf in the default open mode?
>
> - An attacker can access the karaf instance remotely (only has to have IP
> access to the machine)
that's what firewalls are for, and you have those open doors with
internal structures already
so no real new threat here.
> - He can install code from remote sources and run it with the users
> priviledges that karaf runs in. Typically this user is the dev user which in
> many cases is also local system admin
again, firewalls protect internal structures from external attacks.
Internal Attacks are
as usual the main issue, and you don't need an Karaf to expose extra threats.
> - He can read and write all files in reach of that user. Among these are the
> encrypted passwords mentioned above
see above
> - He can install a keylogger and get access to other systems the dev logs
> into. This way he will also get the master password for the encrypted
> passwords
see above
> - He can install software to use the microphone and camera of the machine
it's called "Flame" I think ...
>
> So the question is: Do you trust everyone in the local network?
>
> If no then why should it be a good default to have karaf wide open by
> default?
I think most of your ideas concerning the threats are there but do not
depent on
Karaf but mostly on internal infrastructure. So this is an issue for the admins
of the company. I don't think Karaf exposes new threats.
>
> Christian
>
>
> Am 28.05.2012 14:11, schrieb Achim Nierbeck:
>
>> +1, and to be honest, since we do have a console which is used going to
>> be used by most
>> admins/users where we will prompt some sort of warning we are in a
>> totally different
>> position then tomcat. To achieve something the same with tomcat you need
>> to browse
>> to the starting page of it.
>>
>>>> I really like the ssh agent as it allows a very convenient management of
>>>> several instances and requires only the little effort of copying the
>>>> public
>>>> keys
>>>> to the authorized keys file.
>>>
>>> I think it's too much. Beginners won't just understand why they can't
>>> connect to the karaf instance, have to find some documentation, do the
>>> manipulation. It may take 20 minutes, and people that just want to
>>> give it a try may very well not try that.
>>>
>>>> So the question is if having a default private key is the only option to
>>>> achieve a convenient management. I think we have other options that are
>>>> almost as convenient and
>>>> pose no security risk.
>>>>
>>>> - One option is to log the public keys on the server instance and
>>>> provide a
>>>> command to allow them to connect (add them to the authorized keys)
>>>> - Another option is to provide a command to create a remote instance
>>>> using
>>>> the ssh access to the remote system (similar to fuse fabric). After
>>>> creating
>>>> the instance we could allow to also copy keys. So the instance could be
>>>> reached without a password.
>>>> - For local access using the client command we could create a private
>>>> key in
>>>> the user dir and add it to the authorized keys at first start of karaf.
>>>> So
>>>> the client
>>>> command would work without a password and still be secure.
>>>>
>>>> One good thing about these options is that they also apply to production
>>>> instances while the default private key would never be an option there.
>>>
>>> What you want is a centralized user management system. That's a good
>>> thing to have, I just don't think Karaf has to provide it. That
>>> could be a subproject, but I'm quite sure there are already good
>>> solutions for that.
>>
>> I always thought I'm able to achieve this with JAAS, just plugin the
>> centralized user
>> management available. Like ActiveDirectory / LDAP or what ever one would
>> like.
>>
>>> And I don't think this proposal is good at production time. People
>>> will want to know the key before deployment so that it can be used to
>>> actually access the instance. Having to start the instance, wait
>>> until the key is generated so that you can later be able to log in
>>> does not sound like something very easy. Also any solution that would
>>> involve securing the private key would have to also secure the default
>>> password in the same way.
>>
>> +1, yep I do favor KISS also, and this proposal doesn't sound like KISS.
>>
>>>> Christian
>>>>
>>>>
>>>>
>>>> Am 25.05.2012 18:34, schrieb Guillaume Nodet:
>>>>>
>>>>> So Christian has expressed concerns with the current state:
>>>>>
>>>>> "Currently we create a private key at build time and allow full
>>>>> access with this key by default. I think this opens a big security
>>>>> hole. Of course the same is true for the karaf:karaf user. What makes
>>>>> the private key more dangerous is that people might not see this hole
>>>>> as easily as the default user. So I think we should not do this.
>>>>> Instead I propose to create a key at runtime and use it to connect to
>>>>> the local instance. We could store the generated private key in the
>>>>> user dir to make sure it is at a safe place."
>>>>>
>>>>> We had a chat on IRC so I'll try to summarize my thinking as well.
>>>>>
>>>>> The current state uses a static private key. The main idea was to be
>>>>> able in development mode, to easily access remote instances without
>>>>> any additional configurations. The private key is used by the console
>>>>> (when karaf is started with bin/karaf) and also by the bin/client for
>>>>> default authentication.
>>>>> To disable that (which is obviously bad when putting karaf in
>>>>> production, as I explained in an earlier mail), one has to disable the
>>>>> line in etc/keys.properties and etc/users.properties.
>>>>> This is similar to what we had with the default login / password and
>>>>> hardcoded password in ssh:ssh and bin/client, so I don't really see
>>>>> that as a real problem.
>>>>>
>>>>> I propose to add a warning to the console and log when starting karaf
>>>>> with such a default key enabled (i.e. the default key is available to
>>>>> log in) instead, so that we could keep the ability to easily connect
>>>>> to any instance at development time without additional configuration.
>>>>>
>>>>> Thoughts welcomed.
>>>>>
>>>>> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gn...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
>>>>>> it to trunk next week).
>>>>>> This changes the way the ssh authentication default mechanism works to
>>>>>> leverage ssh agent forwarding and key based authentication.
>>>>>> In short, the default ssh and admin:connect command don't use the
>>>>>> karaf/karaf login/password authentication by default, but use the ssh
>>>>>> agent instead.
>>>>>> The default console uses an internal key which is accepted by adding
>>>>>> the public part in etc/authorized_keys and a local ssh agent which
>>>>>> will be used by default when using ssh / admin:connect command.
>>>>>> When connecting from the outside, one should use the ssh agent
>>>>>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>>>>>> allow you to automatically connect to other karaf instances if the key
>>>>>> is supported too.
>>>>>> Basically, what this means is that the usual default (i.e. you don't
>>>>>> have to specify the password anyway) should work in a real environment
>>>>>> where the default password / key has been changed.
>>>>>>
>>>>>> One thing I just realized I forgot is to enhance the bin/client script
>>>>>> to also use the same private key by default.
>>>>>> Another thing I found (and need to fix), is that the public key
>>>>>> authentication mechanism does not really check the association between
>>>>>> the key used and the user: i.e. any username can be used with any
>>>>>> known key, which is quite bad. Possible enhancements also include a
>>>>>> way to change the "default" key which is used when starting a usual
>>>>>> karaf ; however, given I don't think that's much used in real
>>>>>> production environment, I think this is quite minor and kinda force
>>>>>> the user to use karaf the "right" way. The first step before putting
>>>>>> karaf in prod would be to disallow the default public key and start
>>>>>> karaf using bin/start instead of bin/karaf.
>>>>>>
>>>>>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>>>>>
>>>>>> I'll fix some of the above things next week, and I then plan to start
>>>>>> working on role based authentication on the shell somehow (one thing
>>>>>> we can imagine is a su/sudo mode or something similar). I really
>>>>>> can't bear the confirmation that are prompted any time you want to do
>>>>>> something with bundles anymore, so I think it's time for something
>>>>>> more powerful and flexible.
>>>>>>
>>>>>> --
>>>>>> ------------------------
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> FuseSource, Integration everywhere
>>>>>> http://fusesource.com
>>>>>
>>>>>
>>>> --
>>>>
>>>> Christian Schneider
>>>> http://www.liquid-reality.de
>>>>
>>>> Open Source Architect
>>>> Talend Application Integration Division http://www.talend.com
>>>>
>>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Christian Schneider <ch...@die-schneider.net>.
If the majority of dev here is ok with a warning I go with it but let me
explain some scenarios that make me concerned.
First as Guillaume noted already we have to treat the default user
karaf/karaf in the same way as the default private key.
So the argument for a default of an open access to karaf is that it will
just be used on dev machines and is no problem there. So lets examine
what a developer
has access to and uses from its machine:
- Company Mail account, private Mail account
- File shares of the company. Often very sensitive informations
- Often access to the HR system of the company with sensitive
information like salary
- Access to online banking
- Many devs are also admins. So they access production systems. Often
devs have a file with encrypted passwords that they access with a master
password
So these are resources that I think should be protected well.
So what are the risks when running karaf in the default open mode?
- An attacker can access the karaf instance remotely (only has to have
IP access to the machine)
- He can install code from remote sources and run it with the users
priviledges that karaf runs in. Typically this user is the dev user
which in many cases is also local system admin
- He can read and write all files in reach of that user. Among these are
the encrypted passwords mentioned above
- He can install a keylogger and get access to other systems the dev
logs into. This way he will also get the master password for the
encrypted passwords
- He can install software to use the microphone and camera of the machine
So the question is: Do you trust everyone in the local network?
If no then why should it be a good default to have karaf wide open by
default?
Christian
Am 28.05.2012 14:11, schrieb Achim Nierbeck:
> +1, and to be honest, since we do have a console which is used going to
> be used by most
> admins/users where we will prompt some sort of warning we are in a
> totally different
> position then tomcat. To achieve something the same with tomcat you need
> to browse
> to the starting page of it.
>
>>> I really like the ssh agent as it allows a very convenient management of
>>> several instances and requires only the little effort of copying the public
>>> keys
>>> to the authorized keys file.
>> I think it's too much. Beginners won't just understand why they can't
>> connect to the karaf instance, have to find some documentation, do the
>> manipulation. It may take 20 minutes, and people that just want to
>> give it a try may very well not try that.
>>
>>> So the question is if having a default private key is the only option to
>>> achieve a convenient management. I think we have other options that are
>>> almost as convenient and
>>> pose no security risk.
>>>
>>> - One option is to log the public keys on the server instance and provide a
>>> command to allow them to connect (add them to the authorized keys)
>>> - Another option is to provide a command to create a remote instance using
>>> the ssh access to the remote system (similar to fuse fabric). After creating
>>> the instance we could allow to also copy keys. So the instance could be
>>> reached without a password.
>>> - For local access using the client command we could create a private key in
>>> the user dir and add it to the authorized keys at first start of karaf. So
>>> the client
>>> command would work without a password and still be secure.
>>>
>>> One good thing about these options is that they also apply to production
>>> instances while the default private key would never be an option there.
>> What you want is a centralized user management system. That's a good
>> thing to have, I just don't think Karaf has to provide it. That
>> could be a subproject, but I'm quite sure there are already good
>> solutions for that.
> I always thought I'm able to achieve this with JAAS, just plugin the
> centralized user
> management available. Like ActiveDirectory / LDAP or what ever one would
> like.
>
>> And I don't think this proposal is good at production time. People
>> will want to know the key before deployment so that it can be used to
>> actually access the instance. Having to start the instance, wait
>> until the key is generated so that you can later be able to log in
>> does not sound like something very easy. Also any solution that would
>> involve securing the private key would have to also secure the default
>> password in the same way.
> +1, yep I do favor KISS also, and this proposal doesn't sound like KISS.
>
>>> Christian
>>>
>>>
>>>
>>> Am 25.05.2012 18:34, schrieb Guillaume Nodet:
>>>> So Christian has expressed concerns with the current state:
>>>>
>>>> "Currently we create a private key at build time and allow full
>>>> access with this key by default. I think this opens a big security
>>>> hole. Of course the same is true for the karaf:karaf user. What makes
>>>> the private key more dangerous is that people might not see this hole
>>>> as easily as the default user. So I think we should not do this.
>>>> Instead I propose to create a key at runtime and use it to connect to
>>>> the local instance. We could store the generated private key in the
>>>> user dir to make sure it is at a safe place."
>>>>
>>>> We had a chat on IRC so I'll try to summarize my thinking as well.
>>>>
>>>> The current state uses a static private key. The main idea was to be
>>>> able in development mode, to easily access remote instances without
>>>> any additional configurations. The private key is used by the console
>>>> (when karaf is started with bin/karaf) and also by the bin/client for
>>>> default authentication.
>>>> To disable that (which is obviously bad when putting karaf in
>>>> production, as I explained in an earlier mail), one has to disable the
>>>> line in etc/keys.properties and etc/users.properties.
>>>> This is similar to what we had with the default login / password and
>>>> hardcoded password in ssh:ssh and bin/client, so I don't really see
>>>> that as a real problem.
>>>>
>>>> I propose to add a warning to the console and log when starting karaf
>>>> with such a default key enabled (i.e. the default key is available to
>>>> log in) instead, so that we could keep the ability to easily connect
>>>> to any instance at development time without additional configuration.
>>>>
>>>> Thoughts welcomed.
>>>>
>>>> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gn...@gmail.com> wrote:
>>>>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
>>>>> it to trunk next week).
>>>>> This changes the way the ssh authentication default mechanism works to
>>>>> leverage ssh agent forwarding and key based authentication.
>>>>> In short, the default ssh and admin:connect command don't use the
>>>>> karaf/karaf login/password authentication by default, but use the ssh
>>>>> agent instead.
>>>>> The default console uses an internal key which is accepted by adding
>>>>> the public part in etc/authorized_keys and a local ssh agent which
>>>>> will be used by default when using ssh / admin:connect command.
>>>>> When connecting from the outside, one should use the ssh agent
>>>>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>>>>> allow you to automatically connect to other karaf instances if the key
>>>>> is supported too.
>>>>> Basically, what this means is that the usual default (i.e. you don't
>>>>> have to specify the password anyway) should work in a real environment
>>>>> where the default password / key has been changed.
>>>>>
>>>>> One thing I just realized I forgot is to enhance the bin/client script
>>>>> to also use the same private key by default.
>>>>> Another thing I found (and need to fix), is that the public key
>>>>> authentication mechanism does not really check the association between
>>>>> the key used and the user: i.e. any username can be used with any
>>>>> known key, which is quite bad. Possible enhancements also include a
>>>>> way to change the "default" key which is used when starting a usual
>>>>> karaf ; however, given I don't think that's much used in real
>>>>> production environment, I think this is quite minor and kinda force
>>>>> the user to use karaf the "right" way. The first step before putting
>>>>> karaf in prod would be to disallow the default public key and start
>>>>> karaf using bin/start instead of bin/karaf.
>>>>>
>>>>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>>>>
>>>>> I'll fix some of the above things next week, and I then plan to start
>>>>> working on role based authentication on the shell somehow (one thing
>>>>> we can imagine is a su/sudo mode or something similar). I really
>>>>> can't bear the confirmation that are prompted any time you want to do
>>>>> something with bundles anymore, so I think it's time for something
>>>>> more powerful and flexible.
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> FuseSource, Integration everywhere
>>>>> http://fusesource.com
>>>>
>>> --
>>>
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Achim Nierbeck <bc...@googlemail.com>.
Am 26.05.2012 15:42, schrieb Guillaume Nodet:
> On Sat, May 26, 2012 at 2:41 PM, Christian Schneider
> <ch...@die-schneider.net> wrote:
>> As I expressed on IRC I prefer a secure setting by default. If we take a
>> look at tomcat then they had the remote management open
>> but now have it secure by default and you have to activate it by hand. While
>> this is more inconvenient I think it is the only way
>> to make sure people don´t leave it open. Karaf is not yet in widespread use
>> but if we are succesfull it will be used much more in the future.
> As I said, before being widespread, we need Karaf to be easy. When
> Karaf will be as popular and known as Tomcat, I think we could revisit
> our security strategy.
+1, and to be honest, since we do have a console which is used going to
be used by most
admins/users where we will prompt some sort of warning we are in a
totally different
position then tomcat. To achieve something the same with tomcat you need
to browse
to the starting page of it.
>
>> I really like the ssh agent as it allows a very convenient management of
>> several instances and requires only the little effort of copying the public
>> keys
>> to the authorized keys file.
> I think it's too much. Beginners won't just understand why they can't
> connect to the karaf instance, have to find some documentation, do the
> manipulation. It may take 20 minutes, and people that just want to
> give it a try may very well not try that.
>
>> So the question is if having a default private key is the only option to
>> achieve a convenient management. I think we have other options that are
>> almost as convenient and
>> pose no security risk.
>>
>> - One option is to log the public keys on the server instance and provide a
>> command to allow them to connect (add them to the authorized keys)
>> - Another option is to provide a command to create a remote instance using
>> the ssh access to the remote system (similar to fuse fabric). After creating
>> the instance we could allow to also copy keys. So the instance could be
>> reached without a password.
>> - For local access using the client command we could create a private key in
>> the user dir and add it to the authorized keys at first start of karaf. So
>> the client
>> command would work without a password and still be secure.
>>
>> One good thing about these options is that they also apply to production
>> instances while the default private key would never be an option there.
> What you want is a centralized user management system. That's a good
> thing to have, I just don't think Karaf has to provide it. That
> could be a subproject, but I'm quite sure there are already good
> solutions for that.
I always thought I'm able to achieve this with JAAS, just plugin the
centralized user
management available. Like ActiveDirectory / LDAP or what ever one would
like.
>
> And I don't think this proposal is good at production time. People
> will want to know the key before deployment so that it can be used to
> actually access the instance. Having to start the instance, wait
> until the key is generated so that you can later be able to log in
> does not sound like something very easy. Also any solution that would
> involve securing the private key would have to also secure the default
> password in the same way.
+1, yep I do favor KISS also, and this proposal doesn't sound like KISS.
>
>> Christian
>>
>>
>>
>> Am 25.05.2012 18:34, schrieb Guillaume Nodet:
>>> So Christian has expressed concerns with the current state:
>>>
>>> "Currently we create a private key at build time and allow full
>>> access with this key by default. I think this opens a big security
>>> hole. Of course the same is true for the karaf:karaf user. What makes
>>> the private key more dangerous is that people might not see this hole
>>> as easily as the default user. So I think we should not do this.
>>> Instead I propose to create a key at runtime and use it to connect to
>>> the local instance. We could store the generated private key in the
>>> user dir to make sure it is at a safe place."
>>>
>>> We had a chat on IRC so I'll try to summarize my thinking as well.
>>>
>>> The current state uses a static private key. The main idea was to be
>>> able in development mode, to easily access remote instances without
>>> any additional configurations. The private key is used by the console
>>> (when karaf is started with bin/karaf) and also by the bin/client for
>>> default authentication.
>>> To disable that (which is obviously bad when putting karaf in
>>> production, as I explained in an earlier mail), one has to disable the
>>> line in etc/keys.properties and etc/users.properties.
>>> This is similar to what we had with the default login / password and
>>> hardcoded password in ssh:ssh and bin/client, so I don't really see
>>> that as a real problem.
>>>
>>> I propose to add a warning to the console and log when starting karaf
>>> with such a default key enabled (i.e. the default key is available to
>>> log in) instead, so that we could keep the ability to easily connect
>>> to any instance at development time without additional configuration.
>>>
>>> Thoughts welcomed.
>>>
>>> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gn...@gmail.com> wrote:
>>>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
>>>> it to trunk next week).
>>>> This changes the way the ssh authentication default mechanism works to
>>>> leverage ssh agent forwarding and key based authentication.
>>>> In short, the default ssh and admin:connect command don't use the
>>>> karaf/karaf login/password authentication by default, but use the ssh
>>>> agent instead.
>>>> The default console uses an internal key which is accepted by adding
>>>> the public part in etc/authorized_keys and a local ssh agent which
>>>> will be used by default when using ssh / admin:connect command.
>>>> When connecting from the outside, one should use the ssh agent
>>>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>>>> allow you to automatically connect to other karaf instances if the key
>>>> is supported too.
>>>> Basically, what this means is that the usual default (i.e. you don't
>>>> have to specify the password anyway) should work in a real environment
>>>> where the default password / key has been changed.
>>>>
>>>> One thing I just realized I forgot is to enhance the bin/client script
>>>> to also use the same private key by default.
>>>> Another thing I found (and need to fix), is that the public key
>>>> authentication mechanism does not really check the association between
>>>> the key used and the user: i.e. any username can be used with any
>>>> known key, which is quite bad. Possible enhancements also include a
>>>> way to change the "default" key which is used when starting a usual
>>>> karaf ; however, given I don't think that's much used in real
>>>> production environment, I think this is quite minor and kinda force
>>>> the user to use karaf the "right" way. The first step before putting
>>>> karaf in prod would be to disallow the default public key and start
>>>> karaf using bin/start instead of bin/karaf.
>>>>
>>>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>>>
>>>> I'll fix some of the above things next week, and I then plan to start
>>>> working on role based authentication on the shell somehow (one thing
>>>> we can imagine is a su/sudo mode or something similar). I really
>>>> can't bear the confirmation that are prompted any time you want to do
>>>> something with bundles anymore, so I think it's time for something
>>>> more powerful and flexible.
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> FuseSource, Integration everywhere
>>>> http://fusesource.com
>>>
>>>
>>
>> --
>>
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>
>
--
-----
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Guillaume Nodet <gn...@gmail.com>.
On Sat, May 26, 2012 at 2:41 PM, Christian Schneider
<ch...@die-schneider.net> wrote:
> As I expressed on IRC I prefer a secure setting by default. If we take a
> look at tomcat then they had the remote management open
> but now have it secure by default and you have to activate it by hand. While
> this is more inconvenient I think it is the only way
> to make sure people don´t leave it open. Karaf is not yet in widespread use
> but if we are succesfull it will be used much more in the future.
As I said, before being widespread, we need Karaf to be easy. When
Karaf will be as popular and known as Tomcat, I think we could revisit
our security strategy.
>
> I really like the ssh agent as it allows a very convenient management of
> several instances and requires only the little effort of copying the public
> keys
> to the authorized keys file.
I think it's too much. Beginners won't just understand why they can't
connect to the karaf instance, have to find some documentation, do the
manipulation. It may take 20 minutes, and people that just want to
give it a try may very well not try that.
>
> So the question is if having a default private key is the only option to
> achieve a convenient management. I think we have other options that are
> almost as convenient and
> pose no security risk.
>
> - One option is to log the public keys on the server instance and provide a
> command to allow them to connect (add them to the authorized keys)
> - Another option is to provide a command to create a remote instance using
> the ssh access to the remote system (similar to fuse fabric). After creating
> the instance we could allow to also copy keys. So the instance could be
> reached without a password.
> - For local access using the client command we could create a private key in
> the user dir and add it to the authorized keys at first start of karaf. So
> the client
> command would work without a password and still be secure.
>
> One good thing about these options is that they also apply to production
> instances while the default private key would never be an option there.
What you want is a centralized user management system. That's a good
thing to have, I just don't think Karaf has to provide it. That
could be a subproject, but I'm quite sure there are already good
solutions for that.
And I don't think this proposal is good at production time. People
will want to know the key before deployment so that it can be used to
actually access the instance. Having to start the instance, wait
until the key is generated so that you can later be able to log in
does not sound like something very easy. Also any solution that would
involve securing the private key would have to also secure the default
password in the same way.
>
> Christian
>
>
>
> Am 25.05.2012 18:34, schrieb Guillaume Nodet:
>>
>> So Christian has expressed concerns with the current state:
>>
>> "Currently we create a private key at build time and allow full
>> access with this key by default. I think this opens a big security
>> hole. Of course the same is true for the karaf:karaf user. What makes
>> the private key more dangerous is that people might not see this hole
>> as easily as the default user. So I think we should not do this.
>> Instead I propose to create a key at runtime and use it to connect to
>> the local instance. We could store the generated private key in the
>> user dir to make sure it is at a safe place."
>>
>> We had a chat on IRC so I'll try to summarize my thinking as well.
>>
>> The current state uses a static private key. The main idea was to be
>> able in development mode, to easily access remote instances without
>> any additional configurations. The private key is used by the console
>> (when karaf is started with bin/karaf) and also by the bin/client for
>> default authentication.
>> To disable that (which is obviously bad when putting karaf in
>> production, as I explained in an earlier mail), one has to disable the
>> line in etc/keys.properties and etc/users.properties.
>> This is similar to what we had with the default login / password and
>> hardcoded password in ssh:ssh and bin/client, so I don't really see
>> that as a real problem.
>>
>> I propose to add a warning to the console and log when starting karaf
>> with such a default key enabled (i.e. the default key is available to
>> log in) instead, so that we could keep the ability to easily connect
>> to any instance at development time without additional configuration.
>>
>> Thoughts welcomed.
>>
>> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gn...@gmail.com> wrote:
>>>
>>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
>>> it to trunk next week).
>>> This changes the way the ssh authentication default mechanism works to
>>> leverage ssh agent forwarding and key based authentication.
>>> In short, the default ssh and admin:connect command don't use the
>>> karaf/karaf login/password authentication by default, but use the ssh
>>> agent instead.
>>> The default console uses an internal key which is accepted by adding
>>> the public part in etc/authorized_keys and a local ssh agent which
>>> will be used by default when using ssh / admin:connect command.
>>> When connecting from the outside, one should use the ssh agent
>>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>>> allow you to automatically connect to other karaf instances if the key
>>> is supported too.
>>> Basically, what this means is that the usual default (i.e. you don't
>>> have to specify the password anyway) should work in a real environment
>>> where the default password / key has been changed.
>>>
>>> One thing I just realized I forgot is to enhance the bin/client script
>>> to also use the same private key by default.
>>> Another thing I found (and need to fix), is that the public key
>>> authentication mechanism does not really check the association between
>>> the key used and the user: i.e. any username can be used with any
>>> known key, which is quite bad. Possible enhancements also include a
>>> way to change the "default" key which is used when starting a usual
>>> karaf ; however, given I don't think that's much used in real
>>> production environment, I think this is quite minor and kinda force
>>> the user to use karaf the "right" way. The first step before putting
>>> karaf in prod would be to disallow the default public key and start
>>> karaf using bin/start instead of bin/karaf.
>>>
>>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>>
>>> I'll fix some of the above things next week, and I then plan to start
>>> working on role based authentication on the shell somehow (one thing
>>> we can imagine is a su/sudo mode or something similar). I really
>>> can't bear the confirmation that are prompted any time you want to do
>>> something with bundles anymore, so I think it's time for something
>>> more powerful and flexible.
>>>
>>> --
>>> ------------------------
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
>>
>>
>>
>
>
> --
>
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Christian Schneider <ch...@die-schneider.net>.
As I expressed on IRC I prefer a secure setting by default. If we take a
look at tomcat then they had the remote management open
but now have it secure by default and you have to activate it by hand.
While this is more inconvenient I think it is the only way
to make sure people don´t leave it open. Karaf is not yet in widespread
use but if we are succesfull it will be used much more in the future.
I really like the ssh agent as it allows a very convenient management of
several instances and requires only the little effort of copying the
public keys
to the authorized keys file.
So the question is if having a default private key is the only option to
achieve a convenient management. I think we have other options that are
almost as convenient and
pose no security risk.
- One option is to log the public keys on the server instance and
provide a command to allow them to connect (add them to the authorized keys)
- Another option is to provide a command to create a remote instance
using the ssh access to the remote system (similar to fuse fabric).
After creating
the instance we could allow to also copy keys. So the instance could be
reached without a password.
- For local access using the client command we could create a private
key in the user dir and add it to the authorized keys at first start of
karaf. So the client
command would work without a password and still be secure.
One good thing about these options is that they also apply to production
instances while the default private key would never be an option there.
Christian
Am 25.05.2012 18:34, schrieb Guillaume Nodet:
> So Christian has expressed concerns with the current state:
> "Currently we create a private key at build time and allow full
> access with this key by default. I think this opens a big security
> hole. Of course the same is true for the karaf:karaf user. What makes
> the private key more dangerous is that people might not see this hole
> as easily as the default user. So I think we should not do this.
> Instead I propose to create a key at runtime and use it to connect to
> the local instance. We could store the generated private key in the
> user dir to make sure it is at a safe place."
>
> We had a chat on IRC so I'll try to summarize my thinking as well.
>
> The current state uses a static private key. The main idea was to be
> able in development mode, to easily access remote instances without
> any additional configurations. The private key is used by the console
> (when karaf is started with bin/karaf) and also by the bin/client for
> default authentication.
> To disable that (which is obviously bad when putting karaf in
> production, as I explained in an earlier mail), one has to disable the
> line in etc/keys.properties and etc/users.properties.
> This is similar to what we had with the default login / password and
> hardcoded password in ssh:ssh and bin/client, so I don't really see
> that as a real problem.
>
> I propose to add a warning to the console and log when starting karaf
> with such a default key enabled (i.e. the default key is available to
> log in) instead, so that we could keep the ability to easily connect
> to any instance at development time without additional configuration.
>
> Thoughts welcomed.
>
> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gn...@gmail.com> wrote:
>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
>> it to trunk next week).
>> This changes the way the ssh authentication default mechanism works to
>> leverage ssh agent forwarding and key based authentication.
>> In short, the default ssh and admin:connect command don't use the
>> karaf/karaf login/password authentication by default, but use the ssh
>> agent instead.
>> The default console uses an internal key which is accepted by adding
>> the public part in etc/authorized_keys and a local ssh agent which
>> will be used by default when using ssh / admin:connect command.
>> When connecting from the outside, one should use the ssh agent
>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>> allow you to automatically connect to other karaf instances if the key
>> is supported too.
>> Basically, what this means is that the usual default (i.e. you don't
>> have to specify the password anyway) should work in a real environment
>> where the default password / key has been changed.
>>
>> One thing I just realized I forgot is to enhance the bin/client script
>> to also use the same private key by default.
>> Another thing I found (and need to fix), is that the public key
>> authentication mechanism does not really check the association between
>> the key used and the user: i.e. any username can be used with any
>> known key, which is quite bad. Possible enhancements also include a
>> way to change the "default" key which is used when starting a usual
>> karaf ; however, given I don't think that's much used in real
>> production environment, I think this is quite minor and kinda force
>> the user to use karaf the "right" way. The first step before putting
>> karaf in prod would be to disallow the default public key and start
>> karaf using bin/start instead of bin/karaf.
>>
>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>
>> I'll fix some of the above things next week, and I then plan to start
>> working on role based authentication on the shell somehow (one thing
>> we can imagine is a su/sudo mode or something similar). I really
>> can't bear the confirmation that are prompted any time you want to do
>> something with bundles anymore, so I think it's time for something
>> more powerful and flexible.
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Guillaume,
I'm fine with the way it is, and I think a documentation warning
together with a warning in the console is sufficient enough.
Since it's possible to color the input we should put a nice "nasty"
coloring to this warning that'll catch attention.
regards, Achim
Am 25.05.2012 18:34, schrieb Guillaume Nodet:
> So Christian has expressed concerns with the current state:
> "Currently we create a private key at build time and allow full
> access with this key by default. I think this opens a big security
> hole. Of course the same is true for the karaf:karaf user. What makes
> the private key more dangerous is that people might not see this hole
> as easily as the default user. So I think we should not do this.
> Instead I propose to create a key at runtime and use it to connect to
> the local instance. We could store the generated private key in the
> user dir to make sure it is at a safe place."
>
> We had a chat on IRC so I'll try to summarize my thinking as well.
>
> The current state uses a static private key. The main idea was to be
> able in development mode, to easily access remote instances without
> any additional configurations. The private key is used by the console
> (when karaf is started with bin/karaf) and also by the bin/client for
> default authentication.
> To disable that (which is obviously bad when putting karaf in
> production, as I explained in an earlier mail), one has to disable the
> line in etc/keys.properties and etc/users.properties.
> This is similar to what we had with the default login / password and
> hardcoded password in ssh:ssh and bin/client, so I don't really see
> that as a real problem.
>
> I propose to add a warning to the console and log when starting karaf
> with such a default key enabled (i.e. the default key is available to
> log in) instead, so that we could keep the ability to easily connect
> to any instance at development time without additional configuration.
>
> Thoughts welcomed.
>
> On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gn...@gmail.com> wrote:
>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
>> it to trunk next week).
>> This changes the way the ssh authentication default mechanism works to
>> leverage ssh agent forwarding and key based authentication.
>> In short, the default ssh and admin:connect command don't use the
>> karaf/karaf login/password authentication by default, but use the ssh
>> agent instead.
>> The default console uses an internal key which is accepted by adding
>> the public part in etc/authorized_keys and a local ssh agent which
>> will be used by default when using ssh / admin:connect command.
>> When connecting from the outside, one should use the ssh agent
>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>> allow you to automatically connect to other karaf instances if the key
>> is supported too.
>> Basically, what this means is that the usual default (i.e. you don't
>> have to specify the password anyway) should work in a real environment
>> where the default password / key has been changed.
>>
>> One thing I just realized I forgot is to enhance the bin/client script
>> to also use the same private key by default.
>> Another thing I found (and need to fix), is that the public key
>> authentication mechanism does not really check the association between
>> the key used and the user: i.e. any username can be used with any
>> known key, which is quite bad. Possible enhancements also include a
>> way to change the "default" key which is used when starting a usual
>> karaf ; however, given I don't think that's much used in real
>> production environment, I think this is quite minor and kinda force
>> the user to use karaf the "right" way. The first step before putting
>> karaf in prod would be to disallow the default public key and start
>> karaf using bin/start instead of bin/karaf.
>>
>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>
>> I'll fix some of the above things next week, and I then plan to start
>> working on role based authentication on the shell somehow (one thing
>> we can imagine is a su/sudo mode or something similar). I really
>> can't bear the confirmation that are prompted any time you want to do
>> something with bundles anymore, so I think it's time for something
>> more powerful and flexible.
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com
>
>
--
- Apache Karaf<http://karaf.apache.org/> Committer& PMC
- OPS4J Pax Web<http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer& Project Lead
- Blog<http://notizblog.nierbeck.de/>
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Guillaume Nodet <gn...@gmail.com>.
So Christian has expressed concerns with the current state:
"Currently we create a private key at build time and allow full
access with this key by default. I think this opens a big security
hole. Of course the same is true for the karaf:karaf user. What makes
the private key more dangerous is that people might not see this hole
as easily as the default user. So I think we should not do this.
Instead I propose to create a key at runtime and use it to connect to
the local instance. We could store the generated private key in the
user dir to make sure it is at a safe place."
We had a chat on IRC so I'll try to summarize my thinking as well.
The current state uses a static private key. The main idea was to be
able in development mode, to easily access remote instances without
any additional configurations. The private key is used by the console
(when karaf is started with bin/karaf) and also by the bin/client for
default authentication.
To disable that (which is obviously bad when putting karaf in
production, as I explained in an earlier mail), one has to disable the
line in etc/keys.properties and etc/users.properties.
This is similar to what we had with the default login / password and
hardcoded password in ssh:ssh and bin/client, so I don't really see
that as a real problem.
I propose to add a warning to the console and log when starting karaf
with such a default key enabled (i.e. the default key is available to
log in) instead, so that we could keep the ability to easily connect
to any instance at development time without additional configuration.
Thoughts welcomed.
On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
> it to trunk next week).
> This changes the way the ssh authentication default mechanism works to
> leverage ssh agent forwarding and key based authentication.
> In short, the default ssh and admin:connect command don't use the
> karaf/karaf login/password authentication by default, but use the ssh
> agent instead.
> The default console uses an internal key which is accepted by adding
> the public part in etc/authorized_keys and a local ssh agent which
> will be used by default when using ssh / admin:connect command.
> When connecting from the outside, one should use the ssh agent
> forwarding on the client (ssh -l 8101 -A localhost), and that will
> allow you to automatically connect to other karaf instances if the key
> is supported too.
> Basically, what this means is that the usual default (i.e. you don't
> have to specify the password anyway) should work in a real environment
> where the default password / key has been changed.
>
> One thing I just realized I forgot is to enhance the bin/client script
> to also use the same private key by default.
> Another thing I found (and need to fix), is that the public key
> authentication mechanism does not really check the association between
> the key used and the user: i.e. any username can be used with any
> known key, which is quite bad. Possible enhancements also include a
> way to change the "default" key which is used when starting a usual
> karaf ; however, given I don't think that's much used in real
> production environment, I think this is quite minor and kinda force
> the user to use karaf the "right" way. The first step before putting
> karaf in prod would be to disallow the default public key and start
> karaf using bin/start instead of bin/karaf.
>
> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>
> I'll fix some of the above things next week, and I then plan to start
> working on role based authentication on the shell somehow (one thing
> we can imagine is a su/sudo mode or something similar). I really
> can't bear the confirmation that are prompted any time you want to do
> something with bundles anymore, so I think it's time for something
> more powerful and flexible.
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by "Ulhas Bhole (OS)" <ap...@gmail.com>.
Thanks a lot Guillaume,
Regards,
Ulhas Bhole
On 18 May 2012, at 12:58, Jean-Baptiste Onofré wrote:
> Hi Guillaume,
>
> Thanks a lot for the update and the fix !
>
> Regards
> JB
>
> On 05/18/2012 01:56 PM, Guillaume Nodet wrote:
>> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
>> it to trunk next week).
>> This changes the way the ssh authentication default mechanism works to
>> leverage ssh agent forwarding and key based authentication.
>> In short, the default ssh and admin:connect command don't use the
>> karaf/karaf login/password authentication by default, but use the ssh
>> agent instead.
>> The default console uses an internal key which is accepted by adding
>> the public part in etc/authorized_keys and a local ssh agent which
>> will be used by default when using ssh / admin:connect command.
>> When connecting from the outside, one should use the ssh agent
>> forwarding on the client (ssh -l 8101 -A localhost), and that will
>> allow you to automatically connect to other karaf instances if the key
>> is supported too.
>> Basically, what this means is that the usual default (i.e. you don't
>> have to specify the password anyway) should work in a real environment
>> where the default password / key has been changed.
>>
>> One thing I just realized I forgot is to enhance the bin/client script
>> to also use the same private key by default.
>> Another thing I found (and need to fix), is that the public key
>> authentication mechanism does not really check the association between
>> the key used and the user: i.e. any username can be used with any
>> known key, which is quite bad. Possible enhancements also include a
>> way to change the "default" key which is used when starting a usual
>> karaf ; however, given I don't think that's much used in real
>> production environment, I think this is quite minor and kinda force
>> the user to use karaf the "right" way. The first step before putting
>> karaf in prod would be to disallow the default public key and start
>> karaf using bin/start instead of bin/karaf.
>>
>> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>>
>> I'll fix some of the above things next week, and I then plan to start
>> working on role based authentication on the shell somehow (one thing
>> we can imagine is a su/sudo mode or something similar). I really
>> can't bear the confirmation that are prompted any time you want to do
>> something with bundles anymore, so I think it's time for something
>> more powerful and flexible.
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: [HEADS UP] Ssh agent and key authentication support
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Guillaume,
Thanks a lot for the update and the fix !
Regards
JB
On 05/18/2012 01:56 PM, Guillaume Nodet wrote:
> I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
> it to trunk next week).
> This changes the way the ssh authentication default mechanism works to
> leverage ssh agent forwarding and key based authentication.
> In short, the default ssh and admin:connect command don't use the
> karaf/karaf login/password authentication by default, but use the ssh
> agent instead.
> The default console uses an internal key which is accepted by adding
> the public part in etc/authorized_keys and a local ssh agent which
> will be used by default when using ssh / admin:connect command.
> When connecting from the outside, one should use the ssh agent
> forwarding on the client (ssh -l 8101 -A localhost), and that will
> allow you to automatically connect to other karaf instances if the key
> is supported too.
> Basically, what this means is that the usual default (i.e. you don't
> have to specify the password anyway) should work in a real environment
> where the default password / key has been changed.
>
> One thing I just realized I forgot is to enhance the bin/client script
> to also use the same private key by default.
> Another thing I found (and need to fix), is that the public key
> authentication mechanism does not really check the association between
> the key used and the user: i.e. any username can be used with any
> known key, which is quite bad. Possible enhancements also include a
> way to change the "default" key which is used when starting a usual
> karaf ; however, given I don't think that's much used in real
> production environment, I think this is quite minor and kinda force
> the user to use karaf the "right" way. The first step before putting
> karaf in prod would be to disallow the default public key and start
> karaf using bin/start instead of bin/karaf.
>
> Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
>
> I'll fix some of the above things next week, and I then plan to start
> working on role based authentication on the shell somehow (one thing
> we can imagine is a su/sudo mode or something similar). I really
> can't bear the confirmation that are prompted any time you want to do
> something with bundles anymore, so I think it's time for something
> more powerful and flexible.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com