On 12.03.21 08:00, Mitchell Blank Jr wrote: > For easier review (and to spare your inboxes) I just opened it as a PR > on the openssh-portable github mirror here: https://github.com/openssh/openssh-portable/pull/233 ... I have a couple thoughts which might not directly pertain to your proposal, if I may. ------- You will probably get a number of replies pointing out that, as long as both the number of authentications and the number of keypairs involved remain manageable for human supervision, using SSH_AGENT_CONSTRAIN_CONFIRM a.k.a. "ssh-add -c" will make unauthorized use of a forwarded agent much more difficult. The interesting part here, however - at least for me - is that *both* approaches have a common subproblem: Allowing a human to reliably identify the keypair in question as he vets the request. ssh-agent will prompt him with the comment and the fingerprint of the keypair in question. ... anyone learning their (now SHA256) fingerprints by heart? Not me, I'm afraid ... :-3 I presume that people who have a need to use keypairs on a per-role basis will promptly pick up the concept of editing the comment so as to reflect the role it corresponds to. This, however, leaves the issue unsolved that the comments are trivial to *fake*. In a setting where I use a trusted workplace machine and forward the agent a lot, I'd want to be able to discern which keypairs have been loaded straight from the trusted source, and which ones have been loaded from a less-trusted machine, possibly by an attacker trying to "poison" my agent with a keypair he possesses the privkey of so as to look like a legitimate one to me. (Still trying to nail a possible *goal* for that attacker to do this, though. Please bear with me for the moment. :-3 ) As far as the concept of the trusted workplace machine holds, just adding the information whether the keypair was loaded into the agent locally or through a forwarded connection would already help lots. Any chance that that's an easy-to-implement stop-gap measure ... ? ------- Another thing I learnt today is that someone able to talk to my agent through a forwarding can *lock* it with a password *he* generated from scratch. In the scenario of a trusted workplace (with *one* agent being the parent of your window manager that you'll have to logoff-and-log-in-again to restart) and frequent agent forwarding, that sounds like a DoS attack against the user waiting to happen - for example, to keep him busy and distracted while you continue to abuse a still-open agent forwarding to do stuff he *would* otherwise notice and counter. Having the *actual agent* ask for the password to use (per tty or via ssh-askpass) instead of taking it through the forward sounds like a possible stop-gap measure against that DoS, but not everyone uses tty-or-askpass communication with his *agent* and thus has that set up and working, I suppose ... (I wonder what the use case for remote (un)locking even is ... apart from being able to implement the agent forwarding in ssh without adding a filter right from square one?) Regards, -- Jochen Bern Systemingenieur Binect GmbH
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
