It's something I thought about, we would have to make up a bunch of
stuff in the CERT (not a big deal I guess). Although the thing I worry
about is that cert generation requires gathering a major amount of
entropy from /dev/random. It would seriously affect boot time, and it
would potentially pause for a long period to gather more entropy. This
is a problem for headless devices for example, that don't have a
keyboard and mouse connected to them.
On 11/14/11 7:57 AM, Darran Lofthouse wrote:
It would need to be SSL not SSH as we need to support the mechanism
for
both the Native interface and the HTTP interface but I am starting to
like this as an out of the box scenario.
The advantage we have for the browser is we can always display a nice
HTML page when they connect with full instructions, it is the other
mechanisms where we have less opportunity to dynamically provide guidance.
On 11/14/2011 01:42 PM, Bill Burke wrote:
> You could just have the app-server automatically generate the keys for
> you the first time it ever boots (or even every boot cycle). Just have
> the CLI look at a pre-defined directory for the generated key-pair. THe
> idea here is that CLI works perfectly out-of-the-box with no config on
> the same machine as the CLI runs on. What is still protected is a
> remote machine accessing the app-server. This is fine, IMO.
>
> Usability problems still exist though as you would need to import the
> client-auth key into your browser. But, maybe this is a good thing as
> it will require the user to think about how they want to secure the
> app-server.
>
> On 11/14/11 6:40 AM, Max Rydahl Andersen wrote:
>>>>>
>>>>> These will make all examples that uses maven deploy plugin, cli
scripts, arquillian, jboss tools etc. to somehow
>>>>> either tell users to type in their username and full password in
clear text in pom.xml and other files.
>>>>>
>>>>> Which sounds worse to me than a default locked down to only
localhost…but I'm not a security expert :)
>>>>>
>>>>> I was wondering how hard it would be to make the authentication
support key based auth by default and we make
>>>>> the tools use ${user.name} and ${user.home}/.jboss/default.pub and
.priv (or some other name) for the public/private keys ?
>>>>
>>>> You would need a key-based SASL authentication mechanism. There are no
>>>> standard ones as of right now. If you know of a key-based SASL
>>>> mechanism that you think we should support, let me know and we'll
>>>> evaluate it.
>>>
>>> We would have to do noauth + SSL + trust. I think it's an option worth
considering. The big problem though is that we have to have a setup process to generate
the certs, which is greater complexity than the user/pass option. We would have to
generate a host key pair and a client key pair.
>>
>>
>> I'm not an expert on these things at all but eclipse uses
http://www.jcraft.com/jsch/ to manage and create ssh keys and uses the standard .ssh
location's etc.
>>
>> Is something additional needed ?
>>
>> /max
>>
http://about.me/maxandersen
>>
>>
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat