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.
That seems like it would fix the issue here without introducing a major security issue.
To be blunt... If I was security at a company and found out someone was doing this, I would question why they have the right to use git frankly.
Edit: I should have clicked through to the superuser article which answered my question that this is perfectly fine with git and having multiple in .ssh.
So honest question... why did you think this was a necessary "twist" worth the risks of copying those files to a location it should not be?
[includeIf "gitdir:~/Work/"]
path = .gitconfig_work
[includeIf "gitdir:~/OpenSource/"]
path = .gitconfig_opensource
where `Work` is where all of our repos associated with our GitHub EMU go and `OpenSource` is where I clone all of the open source repos I need to contribute to for work. Our EMU policy doesn't allow us to use our EMU accounts on other repos (or maybe this is just a general restriction of EMU) so I have that set-up to use my personal GitHub. Host project1.git
Hostname github.com
IdentityFile ~/.ssh/id_project1_ed25519
IdentitiesOnly yes
And then "git checkout git@project1.git:foo/project1.git" to checkout the file.run "ssh -vvv" and you will see how ssh client decides to look thru that directory. it will try all of them if none are specified.
I am just trying to figure out how we are jumping from storing in ~/.ssh to storing in the repo here.
> This setup is localized to that repo and is entirely self-contained, i.e. you can move the repo to a different path or place it on a thumb drive to a different machine and it will work without reconfiguring.
But also:
> you can move the repo to a different path
Pretty sure this alone is a non issue.
> place it on a thumb drive to a different machine and it will work without reconfiguring.
I go back to this being terrible security. If you loose that drive someone now has your key and the ability to figure out where that key is valid for.
npm install at your own risk then and wait for the breach…