3 ms·
You've hit the nail on the head. If your computer's ssh binary can be compromised so can krd. If the main objective is to prevent other apps in user space from
by sdca 9y ago
You've hit the nail on the head. If your computer's ssh binary can be compromised so can krd.
If the main objective is to prevent other apps in user space from reading unlocked private keys, why not just ssh/sudo into a secondary account where the default shell is set to an ssh client?
- yzmtf2008 9y agoThe point is, even when krd is compromised, the malicious party cannot gain access to your private key. They key is only stored on your phone and you have to physically confirm the login from your phone.
- xorfish 9y agoIs the private key still worth something if the attacker has access to the server?
- gnur 9y agoYes, because the key is still private. Any other machine to witch you can login with that private key is still off limites.
- xorfish 9y agoAh, I was under the assumption that it is standard practice to have a different key for each machine that you log into.
- snorremd 9y agoI think there are no real standard practice or consensus regarding ssh keys and where you need different keys. Some people use one key for each ssh client machine (the machine logged in from), some one key for each ssh server, some use Yubikey to store a single ssh key, etc. Personally I think one key per client is a good way when not using a hardware security module (e.g. yubikey) as the public key then identifies a unique client machine (e.g. your work laptop). This would help identify which client was breached in an eventual attack. I do think however that I would prefer the Kryptonite solution or using a Yubikey going forward.