The askpass.py file in pssh needs to be executable for the "-A/--askpass" option to work. In the current version of the RPM, it is not executable: % ls -l /usr/lib/python2.6/site-packages/psshlib/askpass.py -rw-r--r-- 1 root root 3650 2009-10-20 15:19 /usr/lib/python2.6/site-packages/psshlib/askpass.py % Please let me know if there is any other information I can provide.
Actually, the -A option bizarrely seems to work even though the askpass.py file isn't executable. Let me look into this a little bit before worrying you about it. :)
Okay. I figured out that it works without being executable because OpenSSH uses execlp, which honors the shebang line even when the target isn't executable. So sorry for the noise, but at least I learned something today. :)
It turns out that everything I said in comment #2 was wrong. :) The reason that the "-A" seemed to be working for me was that I actually had a developent copy of psshlib on my Python path, so the system-wide pssh was actually importing my development copy. Oops. So anyway, it turns out that this is indeed a problem in the pssh RPM, and /usr/lib/python2.6/site-packages/psshlib/askpass.py needs to be executable for the "-A" option to work. Sorry for the runaround, but at least it's an easy fix. :)
My testing indicate a problem here, yes. I have not looked at the code, however this seems a bit strange, would it possible to change the code such that askpass.py could stay non executable?
I don't know of any way to get ssh to execute it without it being executable. :) There's a more detailed description of why it needs to be executable here: http://code.google.com/p/parallel-ssh/issues/detail?id=8 Please feel free to join in the discussion on the issue tracker. I would love to hear your opinions about the best way to deal with this. Thanks for your help.
I fixed this in the following way: - added /usr/libexec/pssh/askpass $ cat /usr/libexec/pssh/askpass #! /usr/bin/env python # from psshlib.askpass import password_client as askpass askpass() - changed task.py: --- 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 This way logic and python code stays in python dirs and the executable is in libexec dir as other SSH_ASKPASS bins. TODO: add some magic to setup.py to install /usr/libexec/pssh/askpass Sounds sensible?
I think this seems like a reasonable approach. Would you mind posting the above to the PSSH issue? The Debian package is having the same problem, and it would be great if Fedora and Debian could use the same solution. If you post your solution to the PSSH issue, then we can get feedback from the Debian packager, too. In the meantime, I'll keep on putting thought into the issue. Thanks for your help.
Done. I would prefer a fix upstream first,p lease ping when updated tarball is released.
pssh-2.1-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/pssh-2.1-1.fc12
pssh-2.1-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/pssh-2.1-1.fc13
pssh-2.1-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/pssh-2.1-1.fc11
pssh-2.1-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
pssh-2.1-1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
pssh-2.1-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.