Cycling through a list of possible usernames (after verifying that the SSH port is accessible) is exactly how we handle this issue in Salt Cloud:
https://github.com/saltstack/salt-cloud/blob/develop/saltcloud/clouds/libcloud_aws.py#L169-L189 https://github.com/saltstack/salt-cloud/blob/develop/saltcloud/utils/__init__.py#L207-L250 It's a horrible solution and it drives me crazy, but I have yet to think of another one. It would be pretty awesome to have it solved more gracefully on the libcloud layer. On Fri, Mar 15, 2013 at 4:52 AM, Chris Psaltis <cpsal...@mist.io> 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 <to...@apache.org> 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 < >>> rstr...@linuxfoundation.org >>>> >>>> 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 -- "In order to create, you have to have the willingness, the desire to be challenged, to be learning." -- Ferran Adria (speaking at Harvard, 2011)
