Git development
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Perez-Lopez Áron Ricardo" <perez.aron@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Bug report: parallel fetch tries to unlock SSH keys over and over again
Date: Fri, 24 Jan 2025 20:34:19 +0000	[thread overview]
Message-ID: <Z5P5SwsMC_DKjp5O@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <CAL_k5jZkYG0evQ2L+bCNvPAnePj=WdU-36GujfjRDwm3iX8ynQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

On 2025-01-24 at 19:46:58, Perez-Lopez Áron Ricardo wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
> git fetch --all --tags --prune --jobs=10
> 
> What did you expect to happen? (Expected behavior)
> Being asked for the password of my SSH key, then git updating all of
> the remotes.
> 
> What happened instead? (Actual behavior)
> I get asked for my SSH key many times over, and the fetch does not succeed.
> 
> What's different between what you expected and what actually happened?
> I should only be asked to unlock my SSH key once. All fetch jobs
> should wait for this and then use the unlocked (cached) key.
> 
> Anything else you want to add:
> If I do just `git fetch` and unlock my key (once), it does get added
> to the SSH agent properly, and afterwards I can execute the command
> above with no issues.

While this would be nice, Git doesn't actually prompt your for your SSH
passphrase, so it has no knowledge as to whether a passphrase is needed
or not.  This is usually done either by your SSH client (such as
OpenSSH), or by some tool which functions as an SSH agent (such as a
system keychain).

Git, in fact, couldn't even just query the agent to see if the key is
there because it's possible in some cases to make the agent require a
password for every usage or after a certain amount of time, so even if
the agent has the key, that doesn't mean that it is or isn't accessible
without a password.

The only way that Git does anything related to the password is to pass
the appropriate file descriptors to the SSH process so that the SSH
client can prompt on the terminal if it so chooses.  So regretfully,
there's no change we can make in Git that will address this in a useful
and general way.  As a workaround, you can explicitly add your SSH key
to the agent, or you can use something like a password manager as your
agent (I use 1Password, but there are others) that will prompt you only
once for all uses, which will avoid the competing prompts.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

      parent reply	other threads:[~2025-01-24 20:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-24 19:46 Bug report: parallel fetch tries to unlock SSH keys over and over again Perez-Lopez Áron Ricardo
2025-01-24 19:51 ` rsbecker
2025-01-24 20:18 ` Junio C Hamano
2025-01-24 20:34 ` brian m. carlson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z5P5SwsMC_DKjp5O@tapette.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=perez.aron@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox