So I have never actually tried, but could you not just have multiple SSH keys in your .ssh folder and run the same command in the article telling git specifically which one to use instead of one within the git directory?
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?
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.
Also make sure to put in your user password in a plaintext file in the repo for ease of automation. Add your SSN in case the usb gets lost. A face scan of a blank check could prove useful for future bills.
Do NOT do this. Anyone who gains access to the repo, gains access to all environments. I repeat, DO NOT DO THIS!!!! Do not deploy from your terminal. Do use CI/CD and do use environment variables and secrets to provide those keys from a secure location. DO NOT STORE THEM IN .git!!! All it takes is one dependency to ruin your day.
npm install at your own risk then and wait for the breach…
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.
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.
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.
15 comments
[ 3.1 ms ] story [ 40.6 ms ] threadI couldn’t get past ”Paste the private key file id_ed25519 into the .git directory of your current repo,”
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?
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.
npm install at your own risk then and wait for the breach…
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.
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.