Better visibility into underlying git commands being run?
VolatileDream opened this issue · 2 comments
Running some of the git-subrepo commands can cause multiple connections to git remotes, each requiring their own authentication action. This can be confusing or concerning for users using hardware backed credentials.
Example:
- Create a GPG Authentication key on a Yubikey, and use it for SSH
- Set the policy to "touch everytime" -> require a yubikey touch every time an SSH connection uses that key
- Configure some git subrepos using
git: - Perform git-subrepo actions (eg: push)
- Notice the yubikey flash for touch input, but nothing is printed to the terminal
The Git commands being run are printed when passing the -v flag, but connecting to remotes should probably be printed by default to help users understand why they are being prompted.
You are absolutely correct. I will have to find a way to test this without a yubi key, but I expect just requiring an ssh password with a similar setting would be sufficient.
[...] I expect just requiring an ssh password with a similar setting would be sufficient.
👍 I'd expect that as well.
I recall ssh doing some sort of key caching, but I can't remember if that was by default or not, so there may also be some ssh config required to maximize password prompting. With a quick read over the ssh, ssh-agent, and ssh_config manual pages it looks like the relevant pieces of config would be:
AddKeysToAgent no in .ssh/config:
Specifies whether keys should be automatically added to a running ssh-agent(1). [...] The argument must be no (the default), yes, confirm (optionally followed by a time interval), ask or a time interval.
Or explicitly starting the agent with ssh-agent -t 0s, which would affect both ssh and ssh-add:
Set a default value for the maximum lifetime of identities added to the agent. [...] Without this option the default maximum lifetime is forever.
But it's probably just as simple as unsetting SSH_AUTH_SOCK when running git commands, ie: SSH_AUTH_SOCK= git subrepo ....