thanks for noting this.  i'm trying to sort out what it means that
this doesn't work.  Canonically, stdin is FD 0 and stdout is FD 1
(stderr is FD 2).

ssh_config(5) describes ProxyCommand as:

  The command can be basically anything, and should read from its
  standard input and write to its standard output.

But inetd(8) says that:

 The master socket will then be passed as fd 0 to the server, which
 will then need to accept the incoming connection.

and redir(1) says:

  --inetd 
          Run as a process started from inetd, with the connection
          passed as stdin and stdout on startup.

So there's a conflict between these goals: inetd passes the socket as
a single file descriptor (FD 0, or stdin).  The strace you posted here
shows that redir --inetd is behaving correctly (trying to write to FD
0) according to the way that inetd works.

But that doesn't match up with what OpenSSH's ProxyCommand needs, and
the redir man page itself appears to be confused, since it claims to
use stdin and stdout, when only stdin (FD 0) is used, as required by
inetd.  At the very least the redir man page should be fixed?

Maybe there's some sort of shell-based file descriptor redirection
magic that could be used to coax a ProxyCommand out of redir?

Patches or suggestions are welcome.

As a workaround, you could always use netcat (or socat) as the
ProxyCommand, with something like this:

 nc hostname 22

hth,

        --dkg

Attachment: pgplEH1hJadLe.pgp
Description: PGP signature

Reply via email to