No, only NIST P-521 client keys used with PuTTY are affected. The server host key signature is computed by the server (most likely OpenSSH) which is unaffected.
The approach by ssh-mitm differs quite significantly as already mentioned by Manfred Kaiser in the issue linked above. Most significantly, ssh-mitm basically establishes two connections (one as a server, one as a client) and forwards messages between the two. This however requires the client to accept the hostkey from the MitM (or the MitM to get a hold on the private key of the server's hostkey). In comparison, our attack manipulates a single connection, without the attacker knowing the hostkey or a client accepting a malicious hostkey. For more details, see the issue here: https://github.com/ssh-mitm/ssh-mitm/issues/165
Yes, I commented this over at netgate as well. If you'd like to work around the vulnerability, you will need to disable both, chacha20-poly1305@openssh.com encryption and -etm@openssh.com MACs. Keeping either of them enabled still allows for exploitation.
Actually, you cannot perform keystroke timing attacks on the password sent during SSH user authentication. This is because SSH transmits the password in its entirety, not the individual keystrokes as it does during a shell session.
The possible downgrade is usually limited to downgrading SHA2 to SHA1 when using RSA keys for user authentication. We are currently not aware of any attacks that benefit from this.
> The possible downgrade is usually limited to downgrading SHA2 to SHA1 when using RSA keys for user authentication
AFAIK this downgrade is not possible for OpenSSH, as it refuses RSA/SHA1 signatures by default at both the client and server. Moreover, deleting the EXT_INFO message would only remove the _advertisement_ that these messages are accepted and would change the fact of whether they are.
It might be possible to use this attack to trick an old client to making a RSA/SHA1 signature where it might mormally have made an RSA/SHA2 one, but I can't see any security impact from this as the signed data is still bound to the connection instance and it wouldn't change whether the peer would accept it anyway.
I don't think dropping the server-sig-algs packet gives any additional downgrade capability? If a server is going to accept a rsa sha1 signature it will accept it regardless of whether the client receives the server-sig-algs or not. Performing a rsa sha1 signature doesn't cause any exposure for a client (that I know of?).
server-sig-algs was only added for compatibility, so new clients wouldn't get kicked off old servers that don't accept rsa-sha2 pubkey auth packets. https://www.rfc-editor.org/rfc/rfc8308#page-7
We updated the FAQ question to cover this. For most users, fixing can be done by installing patched versions of their SSH implementations as they come available. If you feel uncomfortable waiting for an update, you may disable the affected cipher modes temporarily and use other modes like AES-GCM instead. But keep in mind that a faulty configuration can cause you to loose access to the server.
Fwiw, I found a bunch of clients and libraries that didn't support AES-GCM at all, or only very recently. libssh2 is one example. That's made me nervous to make AES-GCM the only supported cipher as a mitigation.
Depends a bit on the MAC. CTR-EtM is technically vulnerable (i.e. cryptographically broken), but due to key stream desynchronization the attack will quickly lead to application errors, defeating the attacker. See Sect. 4.3.3.
