https://bugzilla.mindrot.org/show_bug.cgi?id=2319
Matt Johnston <m...@ucc.asn.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m...@ucc.asn.au --- Comment #10 from Matt Johnston <m...@ucc.asn.au> --- (I'm looking at https://datatracker.ietf.org/doc/draft-josefsson-secsh-u2f/?include_text=1 ) I think it would be worth using the 32 byte "challenge" to bind the authentication to the current SSH session. Otherwise an attacker running a SSH server can get their clients to sign a response for another server if they know an entry from authorized_keys (because of origin/appid of ssh://localhost)? Maybe something like challenge = chal_sess_hash | 16_random_bytes where chal_sess_hash is a 16 byte truncated sha256 hash of string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "u2f" The client MUST check that the first 16 bytes is correct - that's slightly more complexity (decoding JSON) though the code's already there for the server. That would also improve resistance to MITM even if the server hostkey is compromised/ignored. Existing SSH public key authentication does that by including the sessionid in the hash being signed (rfc4253 page 9). For integration with SSH I think a constant origin/appid string is probably useful - people expect to be able to connect to a host at varying IPs/hostnames. Copy/pasting from one host's authorized_keys to another is also common practise. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list openssh-bugs@mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-bugs