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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210313/c6ad98f3/attachment-0001.p7s>