Telling Git how to use SSH, nicely
It seems like when you want to do something unusual that one finds another human's interesting configuration and workflows that they found worked for them in their time of need.
The best part is that their pain is shared and skipped by others. In my case, there was this StackOverflow Q/A (How to tell git which private key to use?) that shared the (at the time) new configuration item to set Git's SSH command that's used for pushes and pulls.
However, their command wasn't 100% there for me. I generally use a PGP hardware key with an authentication subkey when using SSH to log into my own hosts and also for VCS forges, like GitHub. This doesn't work very well, at all, for mechanical processes where automation doesn't have access to my hardware key or pin to unlock the hardware token.
Ideally, I'd have a scheduled job that would be able to authenticate and push a snapshot of config to GitHub periodically. Hence finding the aforementioned SO Q/A and wanting to apply this for myself. The wrench was that when I was
sudo-ing as the user to test things out is that it “sees” my hardware token (because it uses an SSH Agent process to handle cryptographic operations) and gracefully falls back to using an on-disk machine-specific SSH key.
So, I got to take advantage of the SO's answerer's suggestion to use
core.sshCommand by setting further options for my use case:
Where they suggested:
git config core.sshCommand "ssh $HOME/.ssh/id_rsa_example -F /dev/null"
I needed to add an option to disable the use of any SSH agent process:
git config core.sshCommand "ssh -o IdentityAgent=none -i $HOME/.ssh/id_rsa_example -F /dev/null"
Flags used here (see man page):
-o OptionKey[=]OptionValue: override/set config value
-F <config-file>: set to
/dev/nullto avoid loading any config files (and avoid loading conflicting or unexpected config)
With that, I can run my SSH commands without having to see a prompt for my hardware token and/or failure to communicate with my user's private SSH agent socket.
Nice. And this allows simple per-repository tuning because its “just”
git-config. Astute readers will also note that this means you can use further conditional configuration to set per-remote and per-ref configuration even!
These are pragmatic bits I found this morning. I hope you find a practical and pragmatic use for them as well. Cheers!