pdsh omitting ssh config options

[GoogleCodeExporter]

Hi

I had a lot of host to manage with hostnames not so easily defined by a regex. 
To be more compicated I have different user names on these host. That is the 
reason why I am using a well configured .ssh/config file (500+ lines without 
comments).

The problem is that pdsh is omitting _SOME_ of the settings, to be more 
precise, it is only using the IdentityFile option as far as I experienced. See 
below:

These are two samples are verifing that I have a correct ssh config file 
(different username than the local one, pubkey works):

ag51@szivattyu # ssh hostone id
uid=214(aggg123) gid=1(staff)
ag51@szivattyu # ssh hosttwo id
uid=513(nem3lehe) gid=1(staff)

Plain pdsh doesn't work. Checking the remote side logs, it is using the local 
username (ag51), which of course didn't works, omitting the ssh config file.

ag51@szivattyu  # pdsh -w hostone -w hosttwo id
hostone: Permission denied, please try again.
hostone: Permission denied, please try again.
hostone: Permission denied (publickey,password,keyboard-interactive).
pdsh@szivattyu: hostone: ssh exited with exit code 255
hosttwo: Permission denied, please try again.
hosttwo: Permission denied, please try again.
hosttwo: Permission denied (publickey,password,keyboard-interactive).
pdsh@szivattyu: hosttwo: ssh exited with exit code 255

Using the -l option explicitly make it work.

ag51@szivattyu  # pdsh -l aggg123 -w hostone -w hosttwo id
hostone: uid=214(aggg123) gid=1(staff)
hosttwo: uid=513(nem3lehe) gid=1(staff)

The problem is, that I didn't use a default private key, so the location is 
only configured in the .ssh/config file, which proofs that pdsh reads some of 
the options from it. 

I took a look at the code, however I'm not a coder, and I figured out, that it 
somehow gets the username from only two sources: the local username, or from 
the -l option. It didn't check the .ssh/config for the username.

Is there any solution for this? As I told the story above, the -l switch is not 
an option in my case, and I don't think that I am the only one who uses such 
.ssh/config files.

Currently I am using dancers shell, but I want to get rid of it for some 
reasons. But dancers shell can use the ssh config file flawless.

Regards,
V. Kandasamy

Original issue reported on code.google.com by neuebede...@gmail.com on 30 Sep 2011 at 5:48

[GoogleCodeExporter]

Ok, off the top of my head I think the issue stems from the fact that pdsh
*always* uses the -l option of ssh(1) to pass the remote username, whether
it is different from the local username or not. It would appear that -l
always overrides settings from .ssh/config, so that is why some other settings
appear to be kept, while the remote username is being overridden.

To test this theory, you can override the default args pdsh uses for ssh using
the PDSH_SSH_ARGS environment variable. By default this variable is:

 "-2 -a -x -l%u %h"

where %u expands to remote username and %h expands to remote hostname. If you 
run

 PDSH_SSH_ARGS="-2 -a -x %h" pdsh -w hostone,hosttwo id

does it work as expected? If so, you can use the env var as a workaround, or you
can edit the default value for PDSH_SSH_ARGS in src/modules/sshcmd.c and 
recompile.
(I can send you a patch if needed)

Eventually the idea is to have a pdsh config file, where the default ssh args
would be set, and at that point you wouldn't need to override the value with
an environment variable.

mark

Original comment by mark.gro...@gmail.com on 30 Sep 2011 at 8:06

• Changed state: Accepted

[GoogleCodeExporter]

Hi Mark,

I though that is a design problem, not a real bug. Defining the PDSH_SSH_ARGS 
without the -l%u option is also not working. 

So the mechanism of ssh for getting username is the following:

if explicitly defined with -l, use it
if not, use from config
if not in config, send the local username

Why not using this? I think only the middle step is missing.

Original comment by neuebede...@gmail.com on 1 Oct 2011 at 5:35

[GoogleCodeExporter]

First, what version of pdsh are you running? I want to make sure that the
PDSH_SSH_ARGS env var is supported in your version.

Also, pdsh is just running ssh with the args I explained earlier, and the rest
is up to the ssh process to decide. It probably would be better if pdsh didn't
pass the -l%u option to ssh(1) when remote username is the same as the local
username. However, pdsh has always run in this way and I would be hesitant to
"fix" it for fear of breaking other users.

From your commands above it does appear that ssh with no args is picking up
the correct remote username. So either PDSH_SSH_ARGS is not supported in your
version of pdsh, or one of the other args used by pdsh is causing ssh to ignore
some configuration.

Could you try

 ssh -2 -a -x hostone id

and

 ssh -2 -a -x hosttwo id

and see if you get the expected results? This should be pretty much exactly
what pdsh is running...

mark

Original comment by mark.gro...@gmail.com on 1 Oct 2011 at 3:16

[GoogleCodeExporter]

Hi,

I think we have now two bugs.

1. PDSH_SSH_ARGS won't work as expected.
2. Wrong usage of -l option with sshcmd module.

I used the following versions and underlaying operating system.

pdsh-2.26 (from ports repository)
pdsh-2.27 (compiled from source)

OS: freebsd amd64 8.2 release

This thread is about the second one, should I open a separate ticket for the 
first?

Original comment by neuebede...@gmail.com on 2 Oct 2011 at 1:12

[GoogleCodeExporter]

Thanks! PDSH_SSH_ARGS should be supported in both of those pdsh versions.
It would be great if you could open an issue on #1 above!

Meanwhile, did you try running

 ssh -2 -a -x hostone id

and

 ssh -2 -a -x hosttwo id

I am interested in whether those exact commands work for you.

Original comment by mark.gro...@gmail.com on 2 Oct 2011 at 2:04

[GoogleCodeExporter]

Ok, I think I've found the problem.
commit beb73c8181641b3ffcbe3d07c32d887d9bab94d8 has a change that always adds
%lu to ssh commandline if no %u is found in the ssh argument list. This was
a fix for Issue 25.

However, now there is no way to override use of -l%u with PDSH_SSH_ARGS, so this
commit introduced a new bug which you so graciously reported.

So, the two issues above are related after all. (No need to open a separate 
issue)
I will try to get a test patch to you tomorrow. The fix will be to disable the
code in commit beb73c81 if no remote username has been set.

At the same time, I will consider whether disabling the explicit -l%u for all
cases when no remote username is set.

Thanks, nice find!
mark

Original comment by mark.gro...@gmail.com on 2 Oct 2011 at 2:26

[GoogleCodeExporter]

If I mimic the ssh module, as mentioned in the source code, it works as 
expected:

ag51@szivattyu # /tmp/dsh227/bin/pdsh -Rexec -w hostone -w hosttwo ssh %h id
hostone: uid=214(aggg123) gid=1(staff)
hosttwo: uid=513(nem3lehe) gid=1(staff)

> At the same time, I will consider whether disabling the 
> explicit -l%u for all cases when no remote username is set.

Ask yourself a simple question: what is the purpose of a distributed shell? The 
answer is simple: issuing a command on a bunch of remote host at the same time. 
This statement presumes that you can log in to all the individual hosts. That 
means that you have your rsh or ssh subsystems configured. From another point 
of view, both rsh and ssh has their own mechanism, why implement another on the 
top of them? The idea behind the -l option is to override the underlaying 
rsh/ssh subsystems defaults/configured settings.

I use since years IBM's distributed shell on AIX, which works the way I 
explained above, as the braindamaged dancers shell does.

So I think disabling the explicit -l%u would be the right step, because that 
isn't what a user used to other distributed shells expecting.

Original comment by neuebede...@gmail.com on 3 Oct 2011 at 5:02

[GoogleCodeExporter]

I agree that disabling explicit -l%u seems like the right approach. I need
to think about it some more though, since the code has been that way for over
10 years, and I need to think about whether anyone could be relying on that
behavior before "fixing" it now.

BTW, for the rsh protocol this is a non-issue because pdsh has its own internal
rsh implementation. Therefore it *always* sends the remote username.

So, for now can you try the attached patch? This patch has the pdsh ssh module 
only
*require* -l%u if ruser and luser are different. Therefore, the test where
you set PDSH_SSH_ARGS="-2 -a -x" should now work.

If I decide that removing -l%u should be the default, 
this will be a future one line patch that redefines the default PDSH_SSH_ARGS.

If you would like, you could open a separate issue for that request. I have a
feeling  it will be the right thing to do, but like I said I'd like some time
to mull it over.

Original comment by mark.gro...@gmail.com on 3 Oct 2011 at 4:59

Attachments:

• issue39.patch

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi, 

I recompiled the source with the patch applied, and it works as I expect.

In between I opened Issue 40, with the request to change the behaviour 
discussed above.

Original comment by neuebede...@gmail.com on 4 Oct 2011 at 4:53

[GoogleCodeExporter]

This issue was updated by revision c1c281d7a46d.

Add test for Issue 39: ssh module always forces the use of -l%u,
even if ruser and luser are the same, and -l%u does not appear
in PDSH_SSH_ARGS.

Original comment by mark.gro...@gmail.com on 19 Oct 2011 at 5:41

[GoogleCodeExporter]

This issue was closed by revision 234df7a0857c.

Original comment by mark.gro...@gmail.com on 19 Oct 2011 at 5:41

• Changed state: Fixed