Short of fixing paramiko which is probably not what we want, imho it would be beneficial to just catch the paramiko exception and throw a libcloud exception that just adds some additional hints as to what could have failed, such as username and key. For most cases that would go a long way.
:rjs On Fri, Mar 15, 2013 at 9:07 PM, Tomaz Muraus <[email protected]> wrote: > 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 > >> > > > > > -- -- *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
