I just spent some time looking into it. It looks like paramiko throws "not a valid DSA private key file" exception if you specify a valid ssh key, but an invalid username.
This is unfortunate, because it makes it impossible to differentiate between actual invalid key file and an invalid username. >From the paramiko debug logs: DEBUG:paramiko.transport:Trying key 4334c61b988ac5eac5152721d2acae08 from > test2.pem > DEBUG:paramiko.transport:userauth is OK > INFO:paramiko.transport:Authentication (publickey) failed. Keep the following things in mind: - test2.pem is in fact a valid and working private key - SSH agent is not used when you specify a password or a key file (we pass 'look_for_keys': False, and 'allow_agent': False to paramiko). This actually seems like a paramiko issue so I will try to dig some more there. On Fri, Mar 15, 2013 at 8:27 PM, Tomaz Muraus <[email protected]> wrote: > Thanks for your feedback. > > I personally think that the first thing we (Libcloud) need to do it detect > and propagate correct exception to the caller. > > For example, if a user provides an invalid username, password or private > key we should throw InvalidAuthenticationCredentials and if an invalid > authentication method is provided we should throw > InvalidAuthenticationMethod. > > Because of how SSH protocol works ( > http://tools.ietf.org/html/rfc4252#section-5.1) we can't detect other or > a more specific errors (please correct me if I'm wrong). > > I also agree that "cycling through usernames" is a hacky solution, but > it's not really much we can do in this case. I'm personally open to adding > something like that once #1 has been figured out as long as a user can > disable it or maybe it should even be off by default. > > On Fri, Mar 15, 2013 at 3:52 AM, Chris Psaltis <[email protected]> wrote: > >> We bumped into this as well as few days ago. >> >> The issue is that you can't suppose beforehand what is the ssh_username >> for a specific image. We currently solve it in our application by creating >> a map of ami ids -> ssh_usernames and passing the correct one to libcloud. >> However, I think this should be handled on the libcloud level. One idea is >> to try/except for several known ssh_usernames, e.g. ec2-user, ubuntu etc. >> It is not very graceful, but probably it's the most robust solution that >> will require less maintenance. >> >> What ideas do you have? I'm willing to implement it next week. >> >> Thanks, >> >> Chris >> >> >> >> >> On 2013-03-15 00:12, Rudolf Streif wrote: >> >>> Thank you, Tomaz. I actually had both issues, username and key. And once >>> I >>> added ssh_key to the mix it actually started working. :) >>> >>> >>> >>> >>> On Thu, Mar 14, 2013 at 11:50 AM, Tomaz Muraus <[email protected]> wrote: >>> >>> Yes, you need to pass ssh_username="ubuntu" kwarg to the deploy_node >>>> method. >>>> >>>> I honestly thought this was documented on the website somewhere, but I >>>> couldn't find it just by quickly glancing over "getting started" and >>>> "docs". This means that even if it is documented somewhere it's not >>>> documented / presented in a good way if I can't find it myself. We will >>>> definitely work on improving the docs and pointing this out >>>> more prominently. >>>> >>>> This thing is also one of the improvements I'm working on for the next >>>> release and some of the improvements are already available in trunk and >>>> 0.12.x branch. >>>> >>>> Currently, even if you use LIBCLOUD_DEBUG functionality, you get a bad / >>>> unrelated exception if you use a correct key, but an invalid SSH >>>> username. >>>> >>>> paramiko library log messages are especially confusing. They don't >>>> indicate >>>> any error and one of them even says something along the lines of >>>> "authentication successful". >>>> >>>> All of this makes for a bad user experience so I will try to figure out >>>> the >>>> best way to detect this issue and throw a more specific exceptions so >>>> people won't be confused and need to waste a lot of time on this. >>>> >>>> On Thu, Mar 14, 2013 at 11:39 AM, Rudolf Streif < >>>> [email protected] >>>> >>>>> wrote: >>>>> >>>> >>>> Thanks, Tomaz. >>>>> >>>>> I tried to use deploy_node with EC2. I used a key pair already existing >>>>> and set the security group right. However, it fails when logging into >>>>> the >>>>> node and trying to deploy the scripts. I am doing this: >>>>> >>>>> node = ec2driver.deploy_node(name='**test-3', image=image, size=size, >>>>> deploy=msd, ex_keyname="key") >>>>> >>>>> The image is a Ubuntu 12.10 64-bit, ami-7539b41c >>>>> The size is t1.micro >>>>> >>>>> The error I am getting is libcloud.compute.types.**DeploymentError: >>>>> <DeploymentError: node=i-11f73563, error=Bad authentication type >>>>> (allowed_types=['publickey']), >>>>> driver=<libcloud.compute.**drivers.ec2.EC2NodeDriver object at >>>>> 0xdb0b90>> >>>>> >>>>> I can log in just fine using ssh. The issue could be that the image >>>>> expects logins as user "ubuntu" rather than root. Can I set the user >>>>> with >>>>> the kwargs? >>>>> >>>>> Thanks, >>>>> Rudi >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> >> >> -- >> mist.io >> down to earth cloud computing >> > >
