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

Reply via email to