Summary: | net-misc/openssh-contrib fails with SecureCRT 9 when HPN is enabled | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Reuben Farrelly <reuben-gentoo-bugzilla> |
Component: | Current packages | Assignee: | Patrick McLean <chutzpah> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | klaus.kusche, robbat2, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=905750 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
sshd debugs with HPN enabled (client cannot connect) sshd debugs with HPN not in USE flag (client with same settings can succesfully connect) sshd debugs with HPN enabled (client cannot connect) |
Description
Reuben Farrelly
2022-01-05 05:33:19 UTC
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 |