Hi All -

I'm running into an issue where clients are closing their connections during 
long-running file transfers over locally-forwarded tunnels in my SSHD-based app.

What seems to be happening is:
1) File transfer (just `curl -O http://localhost:12345/hugefile` on a system 
with SSH invoked via `ssh ... -L12345:<hugefile-webserver>:80`) proceeds 
normally (with admirable performance) until 1024 mb of transfer (i.e. the 
default maxBytes limit of a ServerSession).
2) Rekeying initiated by the server
3) Client sees start of rekeying, but gets another one of the data packets 
instead of the next part of the key renegotiation like it expects, and closes 
the connection with:
Disconnecting: Protocol error: expected packet type 31, got 94
4) If multiple similar fetches happen concurrently (i.e. a large binary update 
being delivered to 4+ clients simultaneously over locally-forwarded SSH 
tunnels), the SSHD threads on the JVM occasionally (but reliably, after about 4 
download attempts) deadlock, and all client connections are closed after the 
server fails to receive beacons from the connected systems.

As a dev note, turning the rekeying behavior off (via overriding the checkRekey 
method in my extension to ServerSession) fixes the issue.

A couple of questions:
1) Is this a known problem that can be fixed via tuning of the rekey parameters?
2) If not, I'd like to narrow down the problem. Has anyone had any luck getting 
the native sshd-core project running within a Tomcat 7 webapp? Our deployment 
environment requires it to run within a WAR.
--
Sam Gardner
Trustwave | SMART SECURITY ON DEMAND

________________________________

This transmission may contain information that is privileged, confidential, 
and/or exempt from disclosure under applicable law. If you are not the intended 
recipient, you are hereby notified that any disclosure, copying, distribution, 
or use of the information contained herein (including any reliance thereon) is 
strictly prohibited. If you received this transmission in error, please 
immediately contact the sender and destroy the material in its entirety, 
whether in electronic or hard copy format.

Reply via email to