SSH renegotiation is a common cause of issues. In addition of it being prone to bugs, there also seems to be a disagreement on whether the SSH specification allows SSH data packets to be transmitted while a renegotiation is in progress. In most common contemporary SSH clients including of OpenSSH, WinSCP, Filezilla and PuTTY's psftp.exe, this is allowed, while in very old versions of OpenSSH and in SSH.NET (SSH-2.0-Renci.SshNet.SshClient.0.0.1) it is not.
JSCH seems to be a special case, because even though it does allow those packets, there seem to be a bug in their implementation that occasionally leads to hung connection (we have investigated this last year and it appears to occur when the client-side SSH window size happens to be lower than 32KB at the time of reexchange), which is consistent with your results.
However, this also means that the key exchange algorithm in use is not the cause, so forcing a specific scheme is not going to help. For example, the latest beta of SSH.NET (Renci) supports firstname.lastname@example.org, but still fails during renegotiation with the following error:
Unhandled exception. Renci.SshNet.Common.SshException: Message type 94 is not valid in the current context.
at Renci.SshNet.SftpClient.InternalDownloadFile(String path, Stream output, SftpDownloadAsyncResult asyncResult, Action`1 downloadCallback)
at Renci.SshNet.SftpClient.DownloadFile(String path, Stream output, Action`1 downloadCallback)
(Message type 94 is
SSH_MSG_CHANNEL_DATA, an SSH data packet.)
We already have a workaround for older SSH clients that disables data transfer during SSH negotiation. We'll try enabling this by default for JSCH and Renci as well, which would hopefully resolve the problem. I'll mail you a link to a hotfix shortly.
Disabling renegotiation by setting
MaxSessionTransferredBytes could slightly weaken integrity (and to a lesser extent confidentiality) of the SSH session, although only a bit unless you are going to transfer tens of gigabytes over a single session.