Our code only does the username detection when spinning up and provisioning a machine, but it does store the username detected for use throughout that process. After the machine is spun up, it is generally assumed to be managed with Salt (no SSH required!).
One nice thing is that once you've settled upon an OS and an image provider, you can reasonably expect the username to remain consistent. For instance, Bitnami images will always use "bitnami" as their username. Images provided by Canonical will always use "ubuntu" as the username. Anything that Amazon gives you will always use "ec2-user", and a number of other image makers follow suit. A number of image makers also just use "root", even on EC2. And it should be noted that if you find an image you like, you can make a copy that can be modified as needed, including allowing remote root login, and then just use that as your base image. The caveat here is that you have to maintain your own base image. On Fri, Mar 15, 2013 at 10:13 AM, Rudolf Streif <[email protected]> wrote: > 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 <[email protected]> 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 <[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 >> >> >> >> -- >> "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 > > [email protected] > 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 -- "In order to create, you have to have the willingness, the desire to be challenged, to be learning." -- Ferran Adria (speaking at Harvard, 2011)
