Problem with pass protected ssh private key

[GoogleCodeExporter]

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]

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]

Does the "-A" option do what you want?

Original comment by amcna...@gmail.com on 16 Feb 2010 at 7:43

[GoogleCodeExporter]

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]

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]

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]

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]

[deleted comment]

[GoogleCodeExporter]

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]

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]

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]

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]

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]

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]

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]

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]

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:

• askpass

[GoogleCodeExporter]

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]

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]

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]

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]

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]

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]

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