5 ms·

Put SSH keys in .git to make repos USB-portable

24 points by dansjots 10mo ago

runningmike 10mo ago
Is this a joke? It is called “private key” with a reason…
monkpit 10mo ago
This is like leaving your house keys in the lock on the front door and going on vacation.
heyitsdaad 10mo ago
Sorry I’m too paranoid about this stuff. I couldn’t get past ”Paste the private key file id_ed25519 into the .git directory of your current repo,”
- praash 10mo ago
  I stopped worrying after I began protecting all keys with a passphrase.
  - zikduruqe 10mo ago
    I protect mine with GPG for SSH authentication.
  - doug713705 10mo ago
    Then the access of your git repos is protected by a single factor, the private key, since the private key is already in the wild. Copying a private key on a removable storage or to another device than the device that generated it is never a good idea.
  - Ferret7446 10mo ago
    The only use of the passphrase is to give you time to rotate out the key after it's been compromised. It's not meant to be your main line of defense
nerdjon 10mo ago
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?
- whalesalad 10mo ago
  yes. ssh keys can be named whatever and you can have as many of them in your .ssh dir (or any dir) as you want. "id_ed25519.pub" is just a default/convention. 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.
  - nerdjon 10mo ago
    My question was more the git command in the article I was curious about, I have never used that command myself and I was not sure if there was a weird limitation (possibly related to the git context) that it only worked with files within the git repo. I am just trying to figure out how we are jumping from storing in ~/.ssh to storing in the repo here.
    - danillonunes 10mo ago
      Yes, you can run in your local git repo: git config core.sshCommand "ssh -i /home/your_user/.ssh/your_custom_key" (I believe replacing "/home/your_user" with "~" works too) I use this all the time as my main key is ed25519 but some old repositories only support rsa keys. The sshCommand config is, as the name says, the literal ssh command that is used by git when operations that call a remote with ssh (usually push/pull). You can also put other ssh options in there if you need. Another option to achieve the same effect is to setup directly in your ~/.ssh/config: Host your_custom_alias HostName git.domain.com User git IdentityFile ~/.ssh/your_custom_key then instead of "git clone git@git.domain.com:repo.git" you clone it with "git clone your_custom_alias:repo.git" (or you change the remote if is already cloned). In this case you don't need to have to change the git sshCommand option.
ggm 10mo ago
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.
- nine_k 10mo ago
  (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.
  - ggm 10mo ago
    sure. picking a good passphrase is pretty vital.
  - doug713705 10mo ago
    > (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.
vorpalhex 10mo ago
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.
- op00to 10mo ago
  When I put my password in plaintext in git it shows up as ****. Can you try with yours and see if the same thing happens? Share the repo with me so I can check!
reactordev 10mo ago
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…
- deleted 10mo ago
  [deleted]
bastardoperator 10mo ago
No thank you. Use ~/.ssh/config with per-repo Host aliases and IdentityFile directives.
lawn 10mo ago
Is this the kind of security vulnerabilities we'll be seeing as vibe coding and AI slop takes the reins?
- runningmike 10mo ago
  The bad thing is: these kind of blogs are used for LLM trainings. Never trust AI for security advice without thinking and understanding what you do.
cosmic_cheese 10mo ago
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.
- trueismywork 10mo ago
  Best is hardware keys like yubikeys..
- cluckindan 10mo ago
  Use drive encryption, key passphrases and chmod -r 600 ~/.ssh
- mnahkies 10mo ago
  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.
  - cosmic_cheese 10mo ago
    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.
  - perbu 10mo ago
    I have the same and I'm very happy with UX, but less happy about the key leaving the machine.
giancarlostoro 10mo ago
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.
wrxd 10mo ago
I di the exact opposite and only use ssh keys store in secure enclaves. Each device has their own key I have no access to. 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.
- trueismywork 10mo ago
  Yes. This is the way.
- webstrand 10mo ago
  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.
  - OptionOfT 10mo ago
    My main blocker on using `-sk` keys is the fact that I can't get them to work on WSL on Windows.
    - webstrand 10mo ago
      Oh, if I recall WSL is a Ubuntu VM running on top of Windows, so you'd need to configure USB forwarding for your security key. Or run ssh-agent on the windows side and forward it into the VM?
omani 10mo ago
this has to be a joke, right?
pizzafeelsright 10mo ago
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.
davidkl 9mo ago
Literally the worst idea EVER! Period! ever! PERIOD!

24 points by dansjots 10mo ago

runningmike 10mo ago

Is this a joke? It is called “private key” with a reason…

monkpit 10mo ago

This is like leaving your house keys in the lock on the front door and going on vacation.

heyitsdaad 10mo ago

Sorry I’m too paranoid about this stuff. I couldn’t get past ”Paste the private key file id_ed25519 into the .git directory of your current repo,”

praash 10mo ago
I stopped worrying after I began protecting all keys with a passphrase.
- zikduruqe 10mo ago
  I protect mine with GPG for SSH authentication.
- doug713705 10mo ago
  Then the access of your git repos is protected by a single factor, the private key, since the private key is already in the wild. Copying a private key on a removable storage or to another device than the device that generated it is never a good idea.
- Ferret7446 10mo ago
  The only use of the passphrase is to give you time to rotate out the key after it's been compromised. It's not meant to be your main line of defense

nerdjon 10mo ago

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?

whalesalad 10mo ago
yes. ssh keys can be named whatever and you can have as many of them in your .ssh dir (or any dir) as you want. "id_ed25519.pub" is just a default/convention. 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.
- nerdjon 10mo ago
  My question was more the git command in the article I was curious about, I have never used that command myself and I was not sure if there was a weird limitation (possibly related to the git context) that it only worked with files within the git repo. I am just trying to figure out how we are jumping from storing in ~/.ssh to storing in the repo here.
  - danillonunes 10mo ago
    Yes, you can run in your local git repo: git config core.sshCommand "ssh -i /home/your_user/.ssh/your_custom_key" (I believe replacing "/home/your_user" with "~" works too) I use this all the time as my main key is ed25519 but some old repositories only support rsa keys. The sshCommand config is, as the name says, the literal ssh command that is used by git when operations that call a remote with ssh (usually push/pull). You can also put other ssh options in there if you need. Another option to achieve the same effect is to setup directly in your ~/.ssh/config: Host your_custom_alias HostName git.domain.com User git IdentityFile ~/.ssh/your_custom_key then instead of "git clone git@git.domain.com:repo.git" you clone it with "git clone your_custom_alias:repo.git" (or you change the remote if is already cloned). In this case you don't need to have to change the git sshCommand option.

ggm 10mo ago

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.

nine_k 10mo ago
(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.
- ggm 10mo ago
  sure. picking a good passphrase is pretty vital.
- doug713705 10mo ago
  > (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.

vorpalhex 10mo ago

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.

op00to 10mo ago
When I put my password in plaintext in git it shows up as ****. Can you try with yours and see if the same thing happens? Share the repo with me so I can check!

reactordev 10mo ago

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…

deleted 10mo ago
[deleted]

bastardoperator 10mo ago

No thank you. Use ~/.ssh/config with per-repo Host aliases and IdentityFile directives.

lawn 10mo ago

Is this the kind of security vulnerabilities we'll be seeing as vibe coding and AI slop takes the reins?

runningmike 10mo ago
The bad thing is: these kind of blogs are used for LLM trainings. Never trust AI for security advice without thinking and understanding what you do.

cosmic_cheese 10mo ago

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.

trueismywork 10mo ago
Best is hardware keys like yubikeys..
cluckindan 10mo ago
Use drive encryption, key passphrases and chmod -r 600 ~/.ssh
mnahkies 10mo ago
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.
- cosmic_cheese 10mo ago
  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.
- perbu 10mo ago
  I have the same and I'm very happy with UX, but less happy about the key leaving the machine.

giancarlostoro 10mo ago

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.

wrxd 10mo ago

I di the exact opposite and only use ssh keys store in secure enclaves. Each device has their own key I have no access to. 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.

trueismywork 10mo ago
Yes. This is the way.
webstrand 10mo ago
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.
- OptionOfT 10mo ago
  My main blocker on using `-sk` keys is the fact that I can't get them to work on WSL on Windows.
  - webstrand 10mo ago
    Oh, if I recall WSL is a Ubuntu VM running on top of Windows, so you'd need to configure USB forwarding for your security key. Or run ssh-agent on the windows side and forward it into the VM?

omani 10mo ago

this has to be a joke, right?

pizzafeelsright 10mo ago

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.

davidkl 9mo ago

Literally the worst idea EVER! Period! ever! PERIOD!