Problem with pass protected ssh private key
Closed this issue · 23 comments
GoogleCodeExporter commented
What steps will reproduce the problem :
1. Protect your ssh private key with a password.
2. Run pssh :
/tmp/pssh-2.0/bin$ ./pssh -v -h /tmp/hosts.txt -o /tmp/output/ -e
/tmp/error/ ls
[1] 16:38:04 [FAILURE] server1 Exited with error code 255
[2] 16:38:09 [FAILURE] server2 Exited with error code 255
[3] 16:38:10 [FAILURE] server3 Exited with error code 255
3. /tmp/pssh-2.0/bin$ cat /tmp/error/*
ssh_askpass: exec(/usr/lib/pymodules/python2.5/psshlib/askpass.py):
Permission denied
Permission denied (publickey,password).
ssh_askpass: exec(/usr/lib/pymodules/python2.5/psshlib/askpass.py):
Permission denied
Permission denied (publickey,password).
ssh_askpass: exec(/usr/lib/pymodules/python2.5/psshlib/askpass.py):
Permission denied
Permission denied (publickey,password).
Am I missing something ?
Thanks in advance,
Marc
Original issue reported on code.google.com by dooblem...@positon.org on 21 Dec 2009 at 3:42
GoogleCodeExporter commented
It's not a bug, it's a missing feature. It will be great if pssh would ask you
for
your password, but it does not.
Original comment by dr.bro...@gmail.com on 23 Dec 2009 at 12:48
GoogleCodeExporter commented
Does the "-A" option do what you want?
Original comment by amcna...@gmail.com on 16 Feb 2010 at 7:43
GoogleCodeExporter commented
Thanks for your response.
Yes, with the -A option it asks me my password.
But it does exactly the same as before. No matter if I type in the good
password or not.
Can you test it with an ssh protected key on your side ?
Original comment by dooblem...@positon.org on 18 Feb 2010 at 4:53
GoogleCodeExporter commented
Thanks for letting me know that this is still a problem with the -A option. I
will
try to reproduce it and look into the problem. Thanks.
Original comment by amcna...@gmail.com on 18 Feb 2010 at 6:35
GoogleCodeExporter commented
I looked into this a little more, and it looks like this is a packaging bug or
openssh
problem. What distro are you using? What version of ssh do you have (run `ssh
-V`)?
Original comment by amcna...@gmail.com on 18 Feb 2010 at 9:01
GoogleCodeExporter commented
Oh, and can you give me the exact output of pssh when you specify the -A
option, in
addition to letting me know the version of ssh? Thanks.
Original comment by amcna...@gmail.com on 18 Feb 2010 at 9:02
GoogleCodeExporter commented
[deleted comment]
GoogleCodeExporter commented
No problem!
Here it is :
~/telech/pssh-2.0/bin$ mkdir /tmp/output
~/telech/pssh-2.0/bin$ mkdir /tmp/error
~/telech/pssh-2.0/bin$ vi /tmp/hosts.txt
~/telech/pssh-2.0/bin$ ./pssh -v -A -h /tmp/hosts.txt -o /tmp/output/ -e
/tmp/error/ ls
Warning: do not enter your password if anyone else has superuser
privileges or access to your account.
Password:
[1] 15:22:27 [FAILURE] server1 Exited with error code 255
[2] 15:22:27 [FAILURE] server2 Exited with error code 255
mamau@lotus:~/telech/pssh-2.0/bin$ cat /tmp/error/*
ssh_askpass: exec(/usr/lib/pymodules/python2.5/psshlib/askpass.py): Permission
denied
Permission denied (publickey,password).
ssh_askpass: exec(/usr/lib/pymodules/python2.5/psshlib/askpass.py): Permission
denied
Permission denied (publickey,password).
~/telech/pssh-2.0/bin$ ssh -V
OpenSSH_5.3p1 Debian-1, OpenSSL 0.9.8k 25 Mar 2009
.. And I'm under Debian sid unstable.
Original comment by dooblem...@positon.org on 19 Feb 2010 at 2:27
GoogleCodeExporter commented
Okay. It took me a little longer to track this down because I misinterpreted
something in the execve man page. Anyway, this is a packaging bug. Would you
please
open a report with Debian? The Debian package needs to be changed to set the
executable bit for /usr/lib/pymodules/python2.5/psshlib/askpass.py. It looks
like the
same problem is in Fedora, so I'll open a report there.
Original comment by amcna...@gmail.com on 19 Feb 2010 at 6:22
GoogleCodeExporter commented
On Sat, Feb 20, 2010 at 02:54:19PM +1000, Andrew Pollock wrote:
>
> Actually why is /usr/lib/pymodules/python2.5/psshlib/askpass.py being
> executed directly? Shouldn't that get imported and then something called
> from it?
The askpass.py file gets executed by ssh when it needs a password. The ssh man
page
has a pretty good description of how this works:
SSH_ASKPASS If ssh needs a passphrase, it will read the
passphrase from the current terminal if it was run
from a terminal. If ssh does not have a terminal
associated with it but DISPLAY and SSH_ASKPASS are
set, it will execute the program specified by
SSH_ASKPASS and open an X11 window to read the
passphrase. This is particularly useful when call-
ing ssh from a .xsession or related script. (Note
that on some machines it may be necessary to redi-
rect the input from /dev/null to make this work.)
If making askpass.py executable really turns out to be a problem, you could move
askpass.py to someplace like /usr/libexec/pssh/askpass.py and then change
psshlib/task.py to refer to this location explicitly.
Replace the lines:
root, ext = os.path.splitext(os.path.abspath(askpass.__file__))
environ['SSH_ASKPASS'] = '%s.py' % root
with something like:
environ['SSH_ASKPASS'] = '/usr/libexec/pssh/askpass.py'
In pssh version 2.0, you'll need to _copy_ askpass.py to that location (and also
leave it as a read-only module in psshlib). In version 2.1, this will be a
little
bit easier, so you can actually just _move_ the file. Version 2.1 will be
probably
be released in the next week or so.
If it would make it easier, I could make this process a bit simpler, starting in
version 2.1. I could make it so you just change one line at the top of task.py
from
"ASKPASS_PATH = None" to "ASKPASS_PATH = '/usr/libexec/pssh/askpass.py'".
Would this
help? If you would use this, I would be happy to add it, but I won't bother
unless
it would actually make a difference.
Please let me know if you have any questions or ideas, and let me know what you
end
up doing. Thanks for your help.
Original comment by amcna...@gmail.com on 20 Feb 2010 at 6:21
GoogleCodeExporter commented
By the way, if you're trying to reproduce this problem, you don't actually have
to
use a password-protected ssh key. The "-A" option works for any situation
where ssh
wants to prompt for a password. So the simplest reproducing case is to use
"-A" to
try to connect to a remote system for which passwords are allowed but keys are
not
set up.
Original comment by amcna...@gmail.com on 20 Feb 2010 at 6:29
GoogleCodeExporter commented
I figured out how to open a Debian bug report and created one for this issue.
Here's
a link:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570609
Original comment by amcna...@gmail.com on 20 Feb 2010 at 6:32
GoogleCodeExporter commented
Ok, I think you discovered another bug in the Debian version, nice.
Now I totally removed my pssh Debian package, in order to be sure to test the
right
pssh and psshlibs.
I think the -A option only works with hosts asking for a password. It doesn't
work to
unlock the ssh private key.
The tests I made with pssh version 2.0 :
With my ssh protected private key :
ssh SERVER # works well without asking any pass (ssh-agent running with key
unlocked)
pssh-2.0/bin$ ./pssh -v -h /tmp/hosts -o /tmp/output/ -e /tmp/error/ ls
[1] 12:07:05 [FAILURE] SERVER Exited with error code 255
pssh-2.0/bin$ cat /tmp/error/SERVER
Permission denied. Please create SSH keys or use the -A option to
provide a password.
Permission denied (publickey,password).
Same test with -A option and typing in my private key pass :
pssh-2.0/bin$ cat /tmp/error/SERVER
Permission denied (publickey,password).
Same test with -A option and typing in the server pass :
pssh-2.0/bin$ cat /tmp/error/SERVER
Permission denied (publickey,password).
Now when I test with a fresh account with no private key, and -A option, and
typing
in the server pass, It works well.
In fact, there is no need to ask any password in my case, because my private
key is
unlocked by ssh-agent. Just calling ssh works without any pass.
Thanks a lot for your support.
Marc
Original comment by dooblem...@positon.org on 22 Feb 2010 at 11:13
GoogleCodeExporter commented
Ok, I made one test again. Maybe we are searching the wrong way.
I managed to make it work with my ssh private key !!
In fact, I had to tell pssh the right user in the hosts file :
SERVER root
instead of just :
SERVER
I have "User root" in my ~/.ssh/config file, in order to tell ssh to use "root"
as
default user instead of my own username.
SSH called from pssh seems to ignore the user config. No ?
Original comment by dooblem...@positon.org on 22 Feb 2010 at 11:23
GoogleCodeExporter commented
dooblempub, it looks like you found two separate problems. :) Would you mind
posting
the problem from comment #14 as a separate issue? Thanks!
Original comment by amcna...@gmail.com on 22 Feb 2010 at 5:44
GoogleCodeExporter commented
I suggest the following fix:
- create a small wrapper in /usr/libexec/pssh/askpass
(together with other ssh askpass bins) and keep askpass.py as is.
- Change task.py with a simple one liner:
--- task.py~ 2009-10-20 23:20:04.000000000 +0200
+++ task.py 2010-02-22 17:18:13.920299074 +0100
@@ -59,7 +59,8 @@
# askpass.py to get a provided password. If the module file is
# askpass.pyc, we replace the extension.
root, ext = os.path.splitext(os.path.abspath(askpass.__file__))
- environ['SSH_ASKPASS'] = '%s.py' % root
+ #environ['SSH_ASKPASS'] = '%s.py' % root
+ environ['SSH_ASKPASS'] = '/usr/libexec/pssh/askpass'
if askpass_socket:
environ['PSSH_ASKPASS_SOCKET'] = askpass_socket
# Work around a mis-feature in ssh where it won't call SSH_ASKPASS
askpass in libexec attached.
Implemented this gives python logic in python dirs and bins in /usr/libexec,
which is
FHS way.
Original comment by terjeros@gmail.com on 22 Feb 2010 at 6:30
Attachments:
GoogleCodeExporter commented
terjeros, I just added a file to the repository called libexec/pssh_askpass,
which is
basically the same as the file you attached. I also added an executable_path()
function to askpass.py which can try several paths to find an executable pssh.
For
now, the list includes /usr/libexec/pssh/pssh_askpass and
/usr/local/libexec/pssh/pssh_askpass. Take a look and see what you think.
If you like this change, then all I have to do is figure out how to make
setup.py
install the file to /usr/libexec.
Original comment by amcna...@gmail.com on 22 Feb 2010 at 10:31
- Changed state: Started
GoogleCodeExporter commented
Okay, it looks like there's no way to get setup.py to install things to
/usr/libexec.
From the setuptools documentation, "Note, by the way, that this encapsulation
of data
files means that you can't actually install data files to some arbitrary
location on a
user's machine; this is a feature, not a bug."
What if the RPM just copied libexec/pssh_askpass to
/usr/libexec/pssh/pssh_askpass?
Original comment by amcna...@gmail.com on 22 Feb 2010 at 10:55
GoogleCodeExporter commented
You can add something like this:
diff --git a/setup.py b/setup.py
index 84d64e7..b572d74 100644
--- a/setup.py
+++ b/setup.py
@@ -34,5 +34,6 @@ setup(
],
packages = find_packages(),
+ data_files = [('/usr/libexec/pssh', ['bin/askpass'])],
scripts = [os.path.join("bin", p) for p in ["pssh", "pnuke", "prsync", "pslurp",
"pscp"]]
)
However, the execute bit must be set by other means it seems.
Anyway, this is easy to fix in the rpm spec, your call.
Original comment by terjeros@gmail.com on 23 Feb 2010 at 8:53
GoogleCodeExporter commented
I'll keep on looking for a way to get setuptools to set the execute bit. If I
can't
find an easy way to do that, I do have an alternative idea. We could put
pssh-askpass
into bin/ (so setuptools will make it executable) and then make pssh look for
either
/usr/bin/pssh-askpass or /usr/libexec/pssh/pssh-askpass. Then it would be in
/usr/bin
by default, but packagers could move it to /usr/libexec at their discretion.
What do
you think of this idea? Of course, I'll keep trying to find a good way to get
the
execute bit set in setuptools.
Original comment by amcna...@gmail.com on 23 Feb 2010 at 11:20
GoogleCodeExporter commented
I've read some more documentation, blog entries, etc., and as far as I can
tell,
setuptools really doesn't want to deal with anything other than scripts and
modules.
So I'm committing a change that puts pssh-askpass into the bin directory, and
packagers can move this to /usr/libexec. Does that sound good?
Original comment by amcna...@gmail.com on 24 Feb 2010 at 12:08
GoogleCodeExporter commented
I've touched this up one last time, and I think that this is a good, clean
solution.
I've put pssh-askpass into the bin directory, and I added some text to the
INSTALL
file directing packagers to move this from /usr/bin/pssh-askpass to
/usr/libexec/pssh/pssh-askpass. I've done some testing, and it looks like
everything
works in either location.
I think I'm about ready to cut a 2.1 release including this change, and I think
it
will be better for everyone. I'll mark this bug as fixed, but please reopen it
if
you have any reservations about the solution. Thanks to everyone for helping.
Original comment by amcna...@gmail.com on 24 Feb 2010 at 5:45
- Changed state: Fixed
GoogleCodeExporter commented
Thanks, No problem.
Anyway Issue 14 (ssh user config) solved my problem. Once my ssh key is
unlocked,
pssh works fine (no need for -A option).
Original comment by dooblem...@positon.org on 26 Feb 2010 at 1:23