On 01/03/2020 05:34 PM, James Bottomley wrote: > There's nothing in the current ssh public key based process that can > present remote information to the local client. Remote information *external to the SSH authentication procedure itself*. IIUC, at the point where the client starts to authenticate, both sides are already in agreement what the server's (hopefully unique) pubkey is, that the server has demonstrated possession of the matching private key, and which server-side account the client asks to access. In other words, we may not be able to come up with a wrapped key that is unique to the combo of target account and token and kept secret from everyone else, but we can hash us a long-lived ID for the target account alone that at least promises to have some good randomness, if poor secrecy. Would that, compared to doing the token auth essentially memoryless/"first time ever" every time, buy us some worthwhile top-level properties? *Beyond* the "hold, that's a *different* pubkey the server has now!" check that the known_host cacheing already allows *sans* the U2F part? Regards, -- Jochen Bern Systemingenieur Binect GmbH Robert-Koch-Straße 9 64331 Weiterstadt
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
