whirr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Drexler <Hans.Drex...@HumanInference.com>
Subject RE: FYI, possible causes for net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods
Date Thu, 24 Nov 2011 12:07:20 GMT
Thanks for your comments!

From: Andrei Savu [mailto:savu.andrei@gmail.com]
Sent: donderdag 24 november 2011 12:20
To: user@whirr.apache.org
Subject: Re: FYI, possible causes for net.schmizz.sshj.userauth.UserAuthException: Exhausted
available authentication methods


On Thu, Nov 24, 2011 at 1:03 PM, Hans Drexler <Hans.Drexler@humaninference.com<mailto:Hans.Drexler@humaninference.com>>
wrote:
We have been troubled by

net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods

errors when trying to setup a cluster with Whirr. We managed to solve the issue. Below is
a small checklist. Any of the items in this checklist can be the source of this problem. We
will just list them here for the benefits of others. In our case, the problems were caused
by a combination of items 2 and 3 below.


1.       Make sure your SSH key pair does not have a pass phrase.
This is enforced by .properties file validation (starting from 0.3.0 or 0.4.0)


2.       Do not run Whirr as root. Create a non root account to run whirr
You can run Whirr as root if you want but you have to specify a different value for whirr.cluster-user
See http://whirr.apache.org/docs/0.6.0/configuration-guide.html

We tried it, but this did not work for us. Also, from the documentation it is not clear what
valid values for the whirr.cluster-user are. Can you just put any string 'sample', or must
it be an existing user somewhere...   Running whirr as non root avoids the whole issue.

3.       Make sure that the machine running whirr can be reached from the created cloud nodes.
This is not a requirement.

I am not a whirr novice, so maybe you are right. But for us, trying to setup a cluster from
behind a firewall (machine can go out, but not vice-versa) failed consistently. Are you really
sure about this? Could it be that the hadoop recipe has additional requirements? Fact is that
it started working for us when we moved to a machine that could be reached from the created
nodes.


Happy whirring

Hans

In 0.7.0 (coming soon) we have improved the configuration page by documenting some jclouds
specific options relevant to this issue. Expect more improvements in 0.8.0 thanks to changes
in the upcoming jclouds 1.2.2 release.

That is a good thing!

Also note that it's recommended to avoid using small instances like t1.micro for increased
robustness.

-- Andrei Savu / andreisavu.ro<http://andreisavu.ro>


Mime
View raw message