> On Oct 27, 2018, at 18:19, Steffen Prohaska <prohaska@xxxxxx> wrote: > > From: Steffen Prohaska <prohaska@xxxxxx> > Date: Sat, 27 Oct 2018 16:52:57 +0200 > Subject: [PATCH] close stderr of persistent proxy command if not in debug mode > > If the parent becomes a new persistent connection master daemon, stderr > of the proxy command should be detached, too, similar to the master > daemon's stderr, as changed in > openssh-portable@d2d6bf864e52af8491a60dd507f85b74361f5da3, > upstream@4fb726f0fdcb155ad419913cea10dc4afd409d24 and discussed in > bz#1988. Since I haven't received any comments, I'd like to explain in more detail why I think that the patch is relevant. The problem that the patch solves is a variant of the problem discussed in bz#1988 <https://bugzilla.mindrot.org/show_bug.cgi?id=1988>, i.e. scripts that use stderr unexpectedly hang. A specific example with Python: subprocess.run(['ssh', ...'], capture_output=True, ...) will hang if ssh starts a new master connection that uses as proxy command. Python waits for EOF on the stderr child pipe. But it does not receive EOF if the proxy command keeps stderr open. With the proposed patch, it works as expected. The current behavior is confusing and difficult to debug. The direct child process terminates successfully, but sometimes `run()` does not return. It returns if the master connection has already been active, but it hangs if ssh opens a new master connection. One must understand that ssh spawns additional daemon processes, and one of those keeps the stderr pipe open, which is the reason why `run()` does not see EOF and thus does not return. One possible workaround until the patch has been applied is to not use ProxyJump and use ProxyCommand as follows: Host internal.example.org ProxyCommand 2>/dev/null ssh -W %h:%p login.example.org This works because ProxyCommand is executed via a shell `exec ...`, so that `2>/dev/null` closes stderr in the same way as the proposed patch. Steffen
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
