Bug 1977 - ProxyCommand seems to no execute shell commands
Summary: ProxyCommand seems to no execute shell commands
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 5.9p1
Hardware: All All
: P2 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_6_7
  Show dependency treegraph
 
Reported: 2012-02-07 08:02 AEDT by Christoph Anton Mitterer
Modified: 2014-10-08 08:00 AEDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2012-02-07 08:02:30 AEDT
Hi.

The manpage says to ProxyCommand:
>The command string extends to the end of the line,
>and is executed with the user's shell.

So I'd have assumed that the following works:
Host *.exmaple.org
        ProxyCommand ssh -W %h:%p gateway1.exmaple.org || ssh -W %h:%p gateway2.exmaple.org

But it doesn't, even not in modifications like:
        ProxyCommand { ssh -W %h:%p gateway1.exmaple.org ; } || { ssh -W %h:%p gateway2.exmaple.org ; }
or so.

Is this intentional or a bug?

What works however is explicitly invoking another shell:
        ProxyCommand sh -c "ssh -W %h:%p gateway1.exmaple.org || ssh -W %h:%p gateway2.exmaple.org"
but this shouldn't be necessary, should it?

Thx,
Chris.

btw: I guess my intention is clear, if the gateway1 fails, use gateway2. Is there a better way for doing this?
Comment 1 Damien Miller 2012-02-24 11:03:30 AEDT
I don't think that proxy command will work the way you think it will - if the first ssh invocation emits any output or consumes any input then it will break the client's handshake before the second ssh starts.

Anyway, I can't diagnose what's going wrong here without a full log trace (ssh -vvv ...).
Comment 2 Christoph Anton Mitterer 2012-03-03 10:03:29 AEDT
>I don't think that proxy command will work the way you think it
>will - if the first ssh invocation emits any output or consumes
>any input then it will break the client's handshake before the
>second ssh starts.

Well at least it works exactly as wished, when doing it with:
sh -c "ssh -W %h:%p gateway1.exmaple.org || ssh -W
%h:%p gateway2.exmaple.org"


Here is the log output:
$ ssh -vvv gar-ws-etp71.garching.physik.uni-muenchen.de 
OpenSSH_5.9p1 Debian-3, OpenSSL 1.0.0g 18 Jan 2012
debug1: Reading configuration data /home/calestyo/.ssh/config
debug1: /home/calestyo/.ssh/config line 35: Applying options for *.garching.physik.uni-muenchen.de
debug1: /home/calestyo/.ssh/config line 41: Applying options for *.uni-muenchen.de
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -W gar-ws-etp71.garching.physik.uni-muenchen.de:22 gar-sv-login01.garching.physik.uni-muenchen.de  ||  ssh -W gar-ws-etp71.garching.physik.uni-muenchen.de:22 gar-sv-login02.garching.physik.uni-muenchen.de
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/calestyo/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/calestyo/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-4096
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-4096
debug1: identity file /home/calestyo/.ssh/id_rsa-cert type -1
debug1: identity file /home/calestyo/.ssh/id_dsa type -1
debug1: identity file /home/calestyo/.ssh/id_dsa-cert type -1
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/calestyo/.ssh/id_ecdsa" as a RSA1 public key
debug1: identity file /home/calestyo/.ssh/id_ecdsa type 3
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-521
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-521
debug1: identity file /home/calestyo/.ssh/id_ecdsa-cert type -1
debug1: permanently_drop_suid: 1000
ssh: connect to host gar-sv-login01.garching.physik.uni-muenchen.de port 22: Connection refused
ssh_exchange_identification: Connection closed by remote host
$


HTH,
Chris.
Comment 3 Damien Miller 2012-03-30 11:57:51 AEDT
I think I've figured out your problem:

        xasprintf(&tmp, "exec %s", proxy_command);

This is done to avoid a lingering shell for the life of the connection, while still allowing shell expansion of environment variables, etc. If you proxy command requires other shell features then you'll need to provide one explicitly.
Comment 4 Christoph Anton Mitterer 2012-03-30 23:14:51 AEDT
So you basically mean,... it doesn't work by intention, right?

Could you then please update the documentation to reflect this?
I.e. that [just] commands can be executed, but that env-variables (and whatever else works) are expanded. :)
Comment 5 Damien Miller 2013-07-25 12:17:25 AEST
Retarget to openssh-6.4
Comment 6 Damien Miller 2013-07-25 12:20:21 AEST
Retarget 6.3 -> 6.4
Comment 7 Damien Miller 2014-02-06 10:17:37 AEDT
Retarget incomplete bugs / feature requests to 6.6 release
Comment 8 Damien Miller 2014-02-06 10:19:26 AEDT
Retarget incomplete bugs / feature requests to 6.6 release
Comment 9 Damien Miller 2014-04-12 14:48:25 AEST
Retarget to 6.7 release, since 6.6 was mostly bugfixing.
Comment 10 Damien Miller 2014-04-12 14:54:31 AEST
Remove from 6.6 tracking bug
Comment 11 Damien Miller 2014-07-07 18:19:43 AEST
I've updated the ssh_config.5 manual page to indicate that the process is invoked via "exec".
Comment 12 Damien Miller 2014-10-08 08:00:18 AEDT
Close all bugs left open from 6.6 and 6.7 releases.