Skrillor

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.

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.