Created attachment 761327 [details] emerge --info OpenSSH-8.8 and likely earlier appear to have some sort of compatibility issue with SecureCRT clients when the HPN USE flag is enabled. This is with openssh-8.8_p1-r4. The server is a Gentoo x86_64 system. The client starts to connect, and if it has not been able to connect before it is prompted to accept the key for the server side. But after that it fails when the server side disconnects it. Interestingly enough though the problem is not seen from other OpenSSH clients. So in this case I can SSH from another Gentoo system just fine or even a Windows 11 command prompt, but not directly from my Windows machine using SecureCRT. This affects SecureCRT 9.1 and 9.2 (not sure if earlier versions or not). Take the HPN use flag away and recompile and it all works fine again and both SecureCRT and OpenSSH clients can connect normally. This might be related to https://bugs.gentoo.org/719698 but there doesn't appear to be enough information in that bug report to identify the problem. Hopefully with the logs I am about to attach we may be able to identify the root cause. I have a support contract with SecureCRT so I'm happy to engage them if required but as it is the server side disconnecting the client I figure this is the best place to start.
Created attachment 761328 [details] sshd debugs with HPN enabled (client cannot connect)
Created attachment 761329 [details] sshd debugs with HPN not in USE flag (client with same settings can succesfully connect)
Created attachment 761330 [details] sshd debugs with HPN enabled (client cannot connect) Correct debug log
My initial guess is an incompatibility with MTR-AES-CTR. Could you add the following line to your sshd_config, and re-test: DisableMTAES yes I am wondering if we should add this to sshd_config by default for USE=hpn. On modern hardware, the single threaded implementation is often faster with AES-NI. The multithreaded cipher is mostly useful on older hardware without AES-NI support.
Settting: DisableMTAES yes in sshd_config allowed SecureCRT to connect just fine now even with hpn support enabled.
Emerging openssh-contrib now says that "DisableMTAES yes" must be added to sshd_config. However, it must also be added to ssh_config: When ssh-ing or sftp-ing to my webspace provider, my client and my provider's server agree on AES CTR cipher, and the connection breaks immediately after authentification. When disabling HPN on my client, or when adding "DisableMTAES yes" to my ssh_config, ssh and sftp work fine without any changes on the server side. Hence, this is a general problem on the client and the server side, and it is not specific to SecureCRT. So please: * Change the title of this bug. * Change the message in the ebuild (or disable MT AES by default): "DisableMTAES yes" must be added to *both* ssh_config and sshd_config.
(In reply to Klaus Kusche from comment #6) > However, it must also be added to ssh_config: > When ssh-ing or sftp-ing to my webspace provider, > my client and my provider's server agree on AES CTR cipher, > and the connection breaks immediately after authentification. > See bug 905750 as well. It's likely that issue rather than this older one. > Hence, this is a general problem on the client and the server side, > and it is not specific to SecureCRT. > > So please: > > * Change the title of this bug. > Please give a new title.
(In reply to Sam James from comment #7) > (In reply to Klaus Kusche from comment #6) > > However, it must also be added to ssh_config: > > When ssh-ing or sftp-ing to my webspace provider, > > my client and my provider's server agree on AES CTR cipher, > > and the connection breaks immediately after authentification. > > > > See bug 905750 as well. It's likely that issue rather than this older one. I had only a quick look at 905750 and ruled out 905750 because in my case, there was definitely no segfault. But after reading 905750 closely, I noticed that 905750 is a miscompilation problem which does not necessarily result in segfaults. So yes, that might also be the problem. > > Hence, this is a general problem on the client and the server side, > > and it is not specific to SecureCRT. > > > > So please: > > > > * Change the title of this bug. > > > > Please give a new title. Something like net-misc/openssh-contrib: connections closed immediately when HPN with multithreaded AES CTR cipher is used
