Hi all,
I just opened a ticket for this and submitted a patch. Take a look at
https://issues.apache.org/jira/browse/LIBCLOUD-309
Thanks,
Chris
On 2013-03-18 17:28, Rudolf Streif wrote:
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 <to...@apache.org>
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 <to...@apache.org>
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 [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 <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 [2]
down to earth cloud computing
--
--
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 [3]
Linux Foundation Training Schedule: training.linuxfoundation.org [4]
Links:
------
[1] http://tools.ietf.org/html/rfc4252#section-5.1
[2] http://mist.io
[3] http://events.linuxfoundation.org/
[4] http://training.linuxfoundation.org/
--
mist.io
down to earth cloud computing
