> Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned. Of cour

> Not relevant because there's little to gain from hitting a machine twice within an 1 hour window. There's no need to pwn a machine you already pwned. Of course it is relevant. It means that you're unlikely to get anything "pwned". When someone logs in, an authentic request towards host A will appear. Given your proposed attack, a fraudulent request would appear a few seconds later towards "unknown host". The only way such an attack would go through would be if the user was confused which request was the legitimate one (which is clear if one says "unknown"). Otherwise, the user will already have approved the legitimate one, either with a timed or direct approval, neither of which will apply to the fraudulent one. > So instead of being able to pwn all your machines, they can pwn all the machines that you connect to since the first compromise. Better than nothing, but only marginally since you probably visit your important machines somewhat frequently (+ opportunities to piviot between machines). This also means they can access all your github repos since they're on the same host. I am having trouble understanding your wording here, but I believe that you might have misunderstood "timed" approvals as being per login-target (e.g. "accept all github logins for 1 hour"), when they are per login-source (e.g. "accept all logins from my work machine for 1 hour"). If you get someone to do a "timed" approval, it means that you given the pairing data from the workstation that tried to login, you can perform any login within an hour towards any host. Such a timed approval is sort of a bad idea, but note that all approvals are still logged, so the user would at least be aware of the problem. If the user doesn't do timed approvals, then you can only ever "pwn" one machine at a time. However, if the request shouldn't be obviously fraudulent, it would have to be towards a host the person uses often, and it would still have to be using pairing data from the workstation the user is currently working on. Both such attacks fails the usual sanity check: It requires you to already have compromised the user so much that the attack is pointless to do. If you are able to obtain the kryptonite pairing data from a users workstation, needed to either use a timed approval or to make the request not look obviously fraudulent, then you also have the privileges to replace the ssh client with an evil one (e.g., one that signs evil login requests rather than the local one, one that creates persistent evil shell sessions, etc.). With such privileges, all the users machine-local private keys would also be implicitly compromised. The kryptonite key could be abused, but would not be compromised (that is, hosts have been accessed with your privileges, but the key is still safe and does not need rotation).