Put SSH Keys in .git to Make Repos Usb-Portable
Key topics
The idea of storing SSH keys in a Git repository's `.git` directory to make repos "USB-portable" has sparked a heated debate about security best practices. Some commenters, like heyitsdaad, are too paranoid to even consider it, while others, like praash and zikduruqe, suggest protecting keys with passphrases or GPG. The discussion reveals that having multiple SSH keys in the `.ssh` folder and specifying which one to use with Git is a more secure and flexible approach, as pointed out by nerdjon, whalesalad, and danillonunes. This thread feels relevant now as it highlights the ongoing tension between convenience and security in managing SSH keys.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
40
0-12h
Avg / period
10.8
Based on 43 loaded comments
Key moments
- 01Story posted
Dec 17, 2025 at 12:27 PM EST
16 days ago
Step 01 - 02First comment
Dec 17, 2025 at 2:30 PM EST
2h after posting
Step 02 - 03Peak activity
40 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 23, 2025 at 7:00 AM EST
11 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
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.
That seems like it would fix the issue here without introducing a major security issue.
I am just trying to figure out how we are jumping from storing in ~/.ssh to storing in the repo here.
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.
> 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.
Not just the ability to figure it out, but the config is set to use it automatically, so you could easily figure this out on accident.
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.
Hardware keys would be better, but I think this is a decent balance or security vs convenience for my needs ATM.
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.
Or run ssh-agent on the windows side and forward it into the VM?
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.