<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Arial; font-size: 12pt; color: #000000'>It's also a problem with servers with SSD's. I ran into this myself.<br><br>Andy<br><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Jason T. Greene" <jason.greene@redhat.com><br><b>To: </b>"Darran Lofthouse" <darran.lofthouse@jboss.com><br><b>Cc: </b>jboss-as7-dev@lists.jboss.org<br><b>Sent: </b>Monday, November 14, 2011 7:53:38 AM<br><b>Subject: </b>Re: [jboss-as7-dev] How hard would it be to support key based auth by default to make life simpler and more secure ?<br><br>It's something I thought about, we would have to make up a bunch of <br>stuff in the CERT (not a big deal I guess). Although the thing I worry <br>about is that cert generation requires gathering a major amount of <br>entropy from /dev/random. It would seriously affect boot time, and it <br>would potentially pause for a long period to gather more entropy. This <br>is a problem for headless devices for example, that don't have a <br>keyboard and mouse connected to them.<br><br>On 11/14/11 7:57 AM, Darran Lofthouse wrote:<br>> It would need to be SSL not SSH as we need to support the mechanism for<br>> both the Native interface and the HTTP interface but I am starting to<br>> like this as an out of the box scenario.<br>><br>> The advantage we have for the browser is we can always display a nice<br>> HTML page when they connect with full instructions, it is the other<br>> mechanisms where we have less opportunity to dynamically provide guidance.<br>><br>> On 11/14/2011 01:42 PM, Bill Burke wrote:<br>>> You could just have the app-server automatically generate the keys for<br>>> you the first time it ever boots (or even every boot cycle). Just have<br>>> the CLI look at a pre-defined directory for the generated key-pair. THe<br>>> idea here is that CLI works perfectly out-of-the-box with no config on<br>>> the same machine as the CLI runs on. What is still protected is a<br>>> remote machine accessing the app-server. This is fine, IMO.<br>>><br>>> Usability problems still exist though as you would need to import the<br>>> client-auth key into your browser. But, maybe this is a good thing as<br>>> it will require the user to think about how they want to secure the<br>>> app-server.<br>>><br>>> On 11/14/11 6:40 AM, Max Rydahl Andersen wrote:<br>>>>>>><br>>>>>>> These will make all examples that uses maven deploy plugin, cli scripts, arquillian, jboss tools etc. to somehow<br>>>>>>> either tell users to type in their username and full password in clear text in pom.xml and other files.<br>>>>>>><br>>>>>>> Which sounds worse to me than a default locked down to only localhost…but I'm not a security expert :)<br>>>>>>><br>>>>>>> I was wondering how hard it would be to make the authentication support key based auth by default and we make<br>>>>>>> the tools use ${user.name} and ${user.home}/.jboss/default.pub and .priv (or some other name) for the public/private keys ?<br>>>>>><br>>>>>> You would need a key-based SASL authentication mechanism. There are no<br>>>>>> standard ones as of right now. If you know of a key-based SASL<br>>>>>> mechanism that you think we should support, let me know and we'll<br>>>>>> evaluate it.<br>>>>><br>>>>> 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.<br>>>><br>>>><br>>>> 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.<br>>>><br>>>> Is something additional needed ?<br>>>><br>>>> /max<br>>>> http://about.me/maxandersen<br>>>><br>>>><br>>>><br>>>><br>>>> _______________________________________________<br>>>> jboss-as7-dev mailing list<br>>>> jboss-as7-dev@lists.jboss.org<br>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br>>><br>> _______________________________________________<br>> jboss-as7-dev mailing list<br>> jboss-as7-dev@lists.jboss.org<br>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br><br><br>-- <br>Jason T. Greene<br>JBoss AS Lead / EAP Platform Architect<br>JBoss, a division of Red Hat<br>_______________________________________________<br>jboss-as7-dev mailing list<br>jboss-as7-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br></blockquote><br></div></body></html>