can you provide more details under what circumstances the Close takes longer to process than the roundtrip that the RFC prescribes for channel close?

I don't think we can trigger the channel close mechanics without receiving an ack from the remote side, as we wouldn't know where to deliver any messages, so it would lead to dropped data.

ping.

I don't follow.

My issue is that a poorly implemented SSH server could potentially take forever to respond to a channel close which would cause session.Wait() to deadlock.

the channel mechanism is not really suited for error handling/timeout, since both sides have to be in agreement on what to do with the channel. If the remote end can't do that, the proper course of action is shutdown the entire connection.

That's fine with me, if the server doesn't respond in a reasonable amount of time to the channel close, we should just close the connection.

have you seen this problem in practice?

Nope.

you can setup a keepalive. One does this by sending periodic requests (global or channel) with wantReply=true, and closing the connection if replies take too long.

Maybe the SSH client should provide this out of the box, though?

Nah, I think we're talking about different things. Even with SSH Keep Alive, a poorly implemented ssh server could take forever to respond to a channel close, which would cause session.Wait() to deadlock.

It could handle other requests and respond to keep alive fine, just not respond to the channel close.

Going to close as it has been a long time and I'm not sure if this is relevant anymore.