From: Corey Hickey <chickey@xxxxxxxxxx> When a remote-forwarded TCP service is unresponsive, the SSH client can hang after the SSH server sends an EOF. The SSH client receives the EOF and drains the channel output, but continues to wait for data on the channel input. The SSH server won't close the channel until the client does, and the client won't close the channel until it receives data (or an error) from the channel. The client can end up waiting forever if the forwarded TCP service never responds. The analagous situation happens for local-forwarded TCP services, with the roles of the SSH server and client reversed. My attempted fix for each case is to configure the channel to force an input drain upon receiving an EOF. I do not know if this is the right approach, but the test suite continues to pass for me, at least. --- clientloop.c | 1 + serverloop.c | 1 + 2 files changed, 2 insertions(+) diff --git a/clientloop.c b/clientloop.c index 0050f3eb..cd482e5d 100644 --- a/clientloop.c +++ b/clientloop.c @@ -1514,6 +1514,7 @@ client_request_forwarded_tcpip(struct ssh *ssh, const char *request_type, sshbuf_free(b); free(originator_address); free(listen_address); + c->force_drain = 1; return c; } diff --git a/serverloop.c b/serverloop.c index b4c0d82b..486e5277 100644 --- a/serverloop.c +++ b/serverloop.c @@ -470,6 +470,7 @@ server_request_direct_tcpip(struct ssh *ssh, int *reason, const char **errmsg) out: free(originator); free(target); + c->force_drain = 1; return c; } -- 2.35.1 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
