Join GitHub today
Honor openssh out max packet size #455
OpenSSH client requests a value of 16384 for value of
Because paramiko server is not honoring the client's requested value, and there is no protocol negotiation to notify the client as such, when a packet larger than 16384 is received by the OpenSSH client, it will write to stderr:
This is especially difficult for interactive programs that use cursor addressing, as the position of the client cursor then becomes indeterminate. A large-windowed terminal (size ~170x100) using a curses application is very likely to receive this message, which will cause corruption in the output display.
This value is specified in common.py:
If you follow rfc4254 for this declaration,
Then, following SSH-TRANS, which is http://www.ietf.org/rfc/rfc4253.txt for section 6.1, it reads:
We read that it is perfectly legal to request a maximum packet size of 16384 as OpenSSH client does (“or less”).
If we modify
We can see the client emit this message:
This patch suggests separating
Thanks for the detailed write-up, super appreciated!
I wonder if this was worsened by semi-recent work on cleaning up & exposing some of the window/packet size stuff in #372 - though that doesn't really impact how we go ahead with this, is just idle speculation.
Looks good to me offhand (& the test suite does pass, the 'fail' is the travis worker for the 3.4 interpreter timing out, which is their end not ours), I'd like to test it out with my real world workflows but otherwise I'm slotting this into a release.
Not fully confident with this change, though I will describe my findings fully in the pull request. The OpenSSH client requests a maximum packet size of 16384, but this MIN_PACKET_SIZE value of 32768 causes its request to be "clamped" up to 32768, later causing an error to stderr on the OpenSSH client. Suggest then, to delineate MIN_WINDOW_SIZE from MIN_PACKET_SIZE, as they are applied. I don't think there is any minimum value of MIN_PACKET_SIZE, however we can suggest a value of 4096 for now.