| ▲ | palata 16 hours ago | |
That's a valid attack, but one thing is that they only get access this one time, and you may realise that something wrong happened (maybe not). But they won't get your private key. | ||
| ▲ | Liskni_si 16 hours ago | parent [-] | |
> But they won't get your private key. Indeed, that was my point exactly a couple posts up the thread. :-) > you may realise that something wrong happened I think I can iterate on the exact mechanics to make this less likely. I mean it's getting off-topic but the one thing that comes to mind is to enable ControlMaster for all ssh connections which allows any second ssh invocation to skip the auth and just re-use the existing connection. ssh-copy-id is near instant then and doesn't ask anything. At that point you might—rightly so—argue that they're no longer tricking the user into authorising a different operation. Just a reminder that if someone can run code as your local user, they can easily and sneakily gain access elsewhere. Even if you need a yubikey touch to connect there. The original attack idea of timing the yubikey touch for when you normally expect to touch it might still be relevant for a scenario like ssh-agent forwarding to a malicious box. They can't run code as your local user, but can still perhaps trigger the agent to interact with the yubikey. Maybe. | ||