I just use -sk variants with a FIDO authenticator. Being able to port the keys to another trusted machine (i.e. replacing a computer) if I need to is nice. And it's as secure as a secure enclave.
I do prefer to use a unique key for every (local, remote) pair though. It makes revocation more straightforward.
I feel a bit skeeved out about the standard practice of just letting keys hang free and loose in ~/.ssh/ as it is already (leveraging e.g. Secure Enclave on Macs is much better IMO), let alone putting them in a place where they're liable to be unintentionally uploaded or freely accessible to anybody who happens to come into possession of my thumb drive.
I've moved to storing my keys in my password manager, using it as an ssh agent. Means clicking authorize a bit, but also means I'm running a command I'm expecting to use a key then being prompted to authorize (and if it ever prompts unexpectedly I can stop and ask why)
Hardware keys would be better, but I think this is a decent balance or security vs convenience for my needs ATM.
The experience is similar with keys in Secure Enclave. When anything tries to access a key I get a Touch ID prompt which makes it difficult for anything to use it without my knowledge.
Assume these are for deployment to remote services - 'use deploy keys exclusively'
If the bad intent actor has access to the source code they still need to have access to push to the remote repo to issue a deployment.
If they have access to the remote repo they would then have full access to the deployment, I am not certain this is avoidable if one can edit code, push, and have the pipeline deploy as desired.
Car analogy? Key fob in the car in a locked garage. If you have access to the garage you can steal the car. Secure 'enough' for most people because the intrusion happened prior to the deploy.
At that point why not just put it in the home folder of all your devices? I would hate to lose a thumb drive (or have it stolen intentionally) and now someone has full access to my git repository, the freedom to add malware. Foreign hackers would salivate at the thought.
Any time a proposal to put PRIVATE keys into a portable object is raised, I hope to see discussion of the risks.
This is extremely risky for the integrity of the remote copy. If the key is compromised (USB stick lost or acquired by a bad faith actor) then the remote repository is untrustable.
I suppose this is no different to normal keyloss, and some people maintain their keys on removable devices and are exposed to this loss, if the device does not have additional protections.
If it's not a bare (private) key, I suppose then it comes down to the ssh-agent chain over that key, and the strength of your wrapper protection.
(1) Won't an SSH key with a passphrase solve this? Whoever picks up the lost USB stick won't be able to guess a good passphrase.
(2) It seems like a USB key (like Yubikey) combined with a fair amount os USB-attached storage could be a viable product for some applications! The storage could even be encrypted for (some) extra security.
> (1) Won't an SSH key with a passphrase solve this? Whoever picks up the lost USB stick won't be able to guess a good passphrase.
Yes but in that case your passphrase is your only security.
Keeping your private key private, gives you 2 security levels: you must have the key and know the passphrase.
Readit News
Not sure what the author does but I have three devices and keep them for many years. Adding a new ssh key to servers every few years isn’t that bad.
I do prefer to use a unique key for every (local, remote) pair though. It makes revocation more straightforward.
Hardware keys would be better, but I think this is a decent balance or security vs convenience for my needs ATM.
If the bad intent actor has access to the source code they still need to have access to push to the remote repo to issue a deployment.
If they have access to the remote repo they would then have full access to the deployment, I am not certain this is avoidable if one can edit code, push, and have the pipeline deploy as desired.
Car analogy? Key fob in the car in a locked garage. If you have access to the garage you can steal the car. Secure 'enough' for most people because the intrusion happened prior to the deploy.
I couldn’t get past ”Paste the private key file id_ed25519 into the .git directory of your current repo,”
Copying a private key on a removable storage or to another device than the device that generated it is never a good idea.
This is extremely risky for the integrity of the remote copy. If the key is compromised (USB stick lost or acquired by a bad faith actor) then the remote repository is untrustable.
I suppose this is no different to normal keyloss, and some people maintain their keys on removable devices and are exposed to this loss, if the device does not have additional protections.
If it's not a bare (private) key, I suppose then it comes down to the ssh-agent chain over that key, and the strength of your wrapper protection.
(2) It seems like a USB key (like Yubikey) combined with a fair amount os USB-attached storage could be a viable product for some applications! The storage could even be encrypted for (some) extra security.
Yes but in that case your passphrase is your only security. Keeping your private key private, gives you 2 security levels: you must have the key and know the passphrase.