The solution might be interesting to others so I'm posting what Lukas discovered when analyzing logs from Travis:
The error occurred while parsing the first received SFTP protocol packet - it's length was 707406378 which is obviously too long. However, in hexadecimal form, this number is 2A2A2A2A, which represents the ** (four asterisk characters) in ASCII. This is confirmed by the verbose log where the content of the SFTP packet can be clearly seen:
09:55:56.312 DEBUG Sftp(1) SSH: Server is 'SSH-2.0-Sun_SSH_1.1'.
....
10:09:19.198 Verbose SSH: Received packet SSH_MSG_CHANNEL_DATA (1305 bytes).
5E-00-00-00-00-00-00-05-10-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A
2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A-2A
....
The first 9 bytes are the SSH protocol packet (SFTP protocol runs on top of SSH) and the rest should have been an SFTP packet. But instead, it contains what appears to be a banner message, similar to the SSH banner received earlier during SSH authentication. This is the first time we have encountered such behavior.
Now, the question is whether the proper SFTP packet would follow after this unexpected banner packet. If it did, we could easily ignore the banner packet and proceed to communicate with SFTP protocol. But it is not possible to tell from the log whether this is possible (because connection was terminated after the unexpected packet was received)..
We've updated the Rebex SFTP to detect, read and skip this unexpected packet and sent the updated version to Travis. It works fine and this fix will be included in the next public release.
EDIT
The fix is part of build 4060 released in February 2011.
