3 ms·

I wonder whether this really is worth the risk of replacing a system binary. Showing these notifications feels like security theater to me: the agent never hand

by pilif 13y ago

I wonder whether this really is worth the risk of replacing a system binary. Showing these notifications feels like security theater to me: the agent never hands out the key but only signs a nonce with the key, so the operation it does is not really critical. Additionally, ssh itself already prevents you from connecting to spoofed hosts (using the known_hosts mechanism). So in the end we are left with a useless notification (which also only shows up after the action has been done and thus the damage, if you can call it that, has already been done) and zero protection against the real issue (key theft, which any application running under your account can easily do).

thwarted 13y ago
the agent never hands out the key but only signs a nonce with the key, so the operation it does is not really critical The ability to sign is the ability to assert identity. If it's known that you connect to host B and host A is compromised but low value, if you forward your agent to host A, something on host A can use your agent to connect to host B and you wouldn't know. At least with notifications, you'd know something was up. This is why I made it easy to lock and unlock the agent on demand (mentioned in my other comment). Paired with on-demand agent locking, notifications let you know when the transaction is completed and you can lock your agent again. Additionally, ssh itself already prevents you from connecting to spoofed hosts (using the known_hosts mechanism). Only for the first hop. An ssh session on a remote host knows of a different set of host keys than the machine that is running the agent. Unfortunately, there doesn't seem to be a way to reliably identify which of a series of hosts that your agent socket may be forwarded through is using your agent. As for the risk of replacing a system binary, that's why I hooked it through SSH_ASKPASS.

by pilif 13y ago

thwarted 13y ago

the agent never hands out the key but only signs a nonce with the key, so the operation it does is not really critical The ability to sign is the ability to assert identity. If it's known that you connect to host B and host A is compromised but low value, if you forward your agent to host A, something on host A can use your agent to connect to host B and you wouldn't know. At least with notifications, you'd know something was up. This is why I made it easy to lock and unlock the agent on demand (mentioned in my other comment). Paired with on-demand agent locking, notifications let you know when the transaction is completed and you can lock your agent again. Additionally, ssh itself already prevents you from connecting to spoofed hosts (using the known_hosts mechanism). Only for the first hop. An ssh session on a remote host knows of a different set of host keys than the machine that is running the agent. Unfortunately, there doesn't seem to be a way to reliably identify which of a series of hosts that your agent socket may be forwarded through is using your agent. As for the risk of replacing a system binary, that's why I hooked it through SSH_ASKPASS.