I suppose there is not good solution to this and trying multiple possible user names is of course time consuming, and I agree ugly. I wish the image providers would always allow root access as a minimum. Then I could configure it the way I want it from there. It's not more insecure than using a regular username and have it in sudoers anyway.
Joseph, I suppose your code, which I have not looked at yet, then stores the successful username somewhere for the next time. In production I am going to work around the issue with using my own image. That of course allows me to control the user name and/or allow root access via ssh. And it may save me if the provider removes a particular default image. On Fri, Mar 15, 2013 at 6:09 AM, Joseph Hall <perlho...@gmail.com> wrote: > 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) > -- -- *Rudolf J. Streif* Director of Embedded Solutions The Linux Foundation rudolf.str...@linux.com Phone: +1.619.631.5383 Skype: rudolfstreif PGP: RSA 2048/2048 D6E7D28B Linux Foundation Events Schedule: events.linuxfoundation.org Linux Foundation Training Schedule: training.linuxfoundation.org