VPN MTU limit breaks ssh connection to openssh 6.2p2 server

[Flavien Lebarbe]

> On Thu, 7 Nov 2013, Ernst Kratschmer wrote:
> 
> > Dear openssh developer, 
> > 
> > I want to use a Win7 client with putty to access a Linux host running an 
> > openssh 6.2p2 through a VPN connection. These connection worked relatively 
> > flawless with  all versions of openssh up until openssh 6.1p1. Since the 
> > openssh 6.2p2 upgrade the ssh connection fail consistently with a message: 
> > Network error, connection reset by peer. After inspecting the tcp 
> > transmission between the putty client and openssh server it appears that 
> > the maximum MTU limit of 1362 of the VPN connection, causes the server to 
> > break the 1460 byte cipher string into two packets. At that point the ssh 
> > client, putty or openssh, resets the connection. 
> > 
> > This was not a problem with openssh 6.1p1 since the cipher string was only 
> > 1106 bytes and therefore transmitted in one packet. Since I am stuck with 
> > the VPN MTU limit of 1362, I am hoping that you could help in some form to 
> > get the ssh connection working again by, e.g., limit the cipher string to 
> > less than 1322 bytes?

Damien answered :
> I don't think this is something we can fix in OpenSSH.

I don't get it. Could you elaborate on this ?

Please correct me if I'm wrong, but from my point of view, TCP
splitting packets to respect MTU somewhere in transit should not have
any impact at the functionnal level. We should not expect the values
returned by read()/recv() to match those we gave to write()/send().
When read()-ing on a socket, the size returned is at the kernel (or
libc) discretion. If it prefers to send us the data byte by byte, it
is allowed to, and the process is supposed to wait for more data if
it expects more.

I'm not telling it's easy to implement in OpenSSH as I never seriously
looked at the code but saying it cannot be done surprises me.

Thanks for your clues !

Flavien.