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
pgplEH1hJadLe.pgp
Description: PGP signature