You can use U2F with SSH today by making U2F a pam authentication requirement... though this normally requires some copy and paste of the u2f challenge and response since your terminal doesn't know to do that and the ssh client software itself doesn't recognize the U2F challenge.<p>Making it easier would be really nice.<p>The linked post really unclear to me about the security properties provided. This document ( <a href="https://github.com/openssh/openssh-portable/commit/57ecc10628b04c384cbba2fbc87d38b74cd1199d" rel="nofollow">https://github.com/openssh/openssh-portable/commit/57ecc1062...</a> ) is a least a little more clear about what its doing, though it doesn't make an explicit statement about the intended security properties. (So I can't tell if what I'm about to describe is a security break or just simply an attack outside of the security model.)<p>The language of the post implies, or at least is likely to be read as claiming, that an attacker has to possess the id_ecdsa_sk private key and that a compromised token wouldn't be enough to break your security. This is not the case.<p>Lets imagine that your U2F device maker is totally malicious or at least the manufacture of your device compromised (e.g. by substituting it in the post)-- under this assumption they know all the secrets in the device and have tampered with its signing procedure.<p>Given my understanding of the protocol, under that threat model this form of ssh auth is totally insecure: the device can exfiltrate the key-handle (or just the derived private key itself) via the ECDSA nonce.<p>For example, the token knows some attacker pubkey Q, It takes its current secret x and does ECDH with that and Q, hashes the result with the message being signed and uses that as k. The attacker can observe a single signature, compute the same k then just calculate the user's x which is enough for them to authenticate as the user using ecdsa-sa.<p>A simple variation of this allows the device to leak 32-bits of data per signature: use the shared secret to index into an error correcting code over the data-to-be-leaked, and grab 32-bits and add it to k. The leak would allow the attacker to get the key-handle of a third party site without ever having to observe an authenticating signature to that site. N bits of additional secret can be learned by the attacker after observing N/32 signatures.<p>I'm a little unclear about how the enrollment procedure works, but I think nothing about it actually certifies that the public key returned by the device was generated based on the transmitted key handle... If, as I suspect, it doesn't a malicious device doesn't need to bother with any of the above nonce sidechannel stuff, it can simply return a static pubkey regardless of the key handle and simplify the process and the attacker can simply guess your usename and then look up the key in their database to login as you.<p>As such, I don't believe users should consider use of "ecdsa-sk" to be two-factor... and for ones where their threat model includes attackers that could tamper with the hardware manufacture or shipment (e.g. certainly any major state attackers), they should probably not use this authentication mechanism without an additional effort to use strong two factor auth of some kind. (and it would be kind of unfortunate if it reduced their security to just a crappy user-provided password...)<p>I think this is really unfortunate missed opportunity, and potentially an unprecedented increase in exposure of boring ssh installs to state attackers. Use of a HW token is a <i>massive</i> security increase against less cosmic attackers, but users shouldn't have to choose between security against weak attackers and powerful ones.<p>The authentication procedure could have simply included a second ec point in the pubkey (or made the "pubkey" a hash for two ec points which are provided in the signature) and the authentication could have included an additional signature made with an ordinary private key stored in the key file and never presented to the U2F device. This way a malicious U2F device alone wouldn't be enough to compromise the user security, an attacker would also need to steal the key file. This security improvement wouldn't hurt the usability of the system at all, because honest use also still requires the key file. [Super-extra-paranoids-bonus: the second key could be a better trusted curve, or even a PQ safe cryptosystem like SPHINCS]<p>If the goal wasn't to require the key file-- why store the key handle there at all and not just derive it from data sent by the server as in a more typical U2F application? The only other advantage I see is potentially limiting some cros-domain attacks (e.g. where server A provides server B's key handle).