Hi Taylor,

Interesting command. Good to know it exists.
Here's the following output with GIT_TRACE=1

gohurali@gohurali-OptiPlex-990:~/College_Files/testrepo$ GIT_TRACE=1 git push
12:22:37.616907 git.c:344               trace: built-in: git push
12:22:37.617182 run-command.c:640       trace: run_command: GIT_DIR=.git git-remote-https origin https://github.com/gohurali/testrepo.git
Username for 'https://github.com': gohurali
Password for 'https://[email protected]':
12:22:41.925861 run-command.c:640       trace: run_command: .git/hooks/pre-push origin https://github.com/gohurali/testrepo.git
12:22:41.928571 git.c:576               trace: exec: git-lfs pre-push origin https://github.com/gohurali/testrepo.git
12:22:41.928625 run-command.c:640       trace: run_command: git-lfs pre-push origin https://github.com/gohurali/testrepo.git
12:22:41.934674 trace git-lfs: exec: git 'version'
12:22:41.937967 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' 'HEAD' '--symbolic-full-name' 'HEAD'
12:22:41.940261 trace git-lfs: exec: git 'config' '-l'
12:22:41.941522 trace git-lfs: pre-push: refs/heads/master 2692f612a117a2bec70fd7d12ca92f9bc63eabbc refs/heads/master e60a4846e6c8996805a96f2967d9c0d69da643c3
Username for 'https://github.com': gohurali
Password for 'https://[email protected]':
12:22:46.090681 trace git-lfs: creds: git credential fill ("https", "github.com", "")
Username for 'https://github.com': gohurali
Password for 'https://[email protected]':
12:22:50.175212 trace git-lfs: Filled credentials for https://github.com/gohurali/testrepo.git
12:22:50.175383 trace git-lfs: HTTP: POST https://github.com/gohurali/testrepo.git/info/lfs/locks/verify
12:22:50.373000 trace git-lfs: HTTP: 200
12:22:50.373043 trace git-lfs: creds: git credential approve ("https", "github.com", "")
12:22:50.375025 trace git-lfs: HTTP: {"ours":[],"theirs":[],"next_cursor":""}

12:22:50.375114 trace git-lfs: tq: running as batched queue, batch size of 100
12:22:50.375276 trace git-lfs: run_command: git rev-list --stdin --objects --not --remotes=origin --
12:22:50.376030 trace git-lfs: run_command: git cat-file --batch
12:22:50.378655 trace git-lfs: tq: sending batch of size 0
12:22:50.378705 trace git-lfs: filepathfilter: rewrite ".git" as "**/.git/**"
12:22:50.378727 trace git-lfs: filepathfilter: rewrite "**/.git" as "**/.git"
12:22:50.378776 trace git-lfs: filepathfilter: rejecting "tmp" via []
12:22:50.378792 trace git-lfs: filepathfilter: accepting "tmp"
12:22:50.380512 run-command.c:640       trace: run_command: git send-pack --stateless-rpc --helper-status --thin --progress https://github.com/gohurali/testrepo.git/ --stdin
12:22:50.382933 git.c:344               trace: built-in: git send-pack --stateless-rpc --helper-status --thin --progress https://github.com/gohurali/testrepo.git/ --stdin
12:22:50.383451 run-command.c:640       trace: run_command: git pack-objects --all-progress-implied --revs --stdout --thin --delta-base-offset --progress
12:22:50.384624 git.c:344               trace: built-in: git pack-objects --all-progress-implied --revs --stdout --thin --delta-base-offset --progress
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 275 bytes | 275.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/gohurali/testrepo.git
   e60a484..2692f61  master -> master

EDIT: using a test repo to demonstrate issue

Hey @gohurali! Thanks for opening this issue.

During the normal lifetime of a request such as a push, git-lfs will generally need to get credentials a few times - once to actually push content to the remote, as well as some additional API requests to do LFS-specific operations. As such, it's normal for git-lfs to need credentials three times as you're seeing here.

With regards to the prompt itself, I believe that's expected behavior as well. To get credentials, git-lfs checks a few less-common places (such as a .netrc file), and if it doesn't find credentials in those places, falls back on querying git for the credentials it needs.

From the output, it seems you don't have git setup to store credentials in a credential helper, is that correct? If so, git won't store your credentials, which means git will need to prompt you for them every time git-lfs asks for credentials.

You should be able to fix this in one of two ways. First is to set up credential storage for git. This will allow git to store your credentials and use the stored credentials for future requests instead of prompting you. You'll only need to enter your credentials for github.com once, then all future requests to github.com, whether they're made through git or git-lfs, will use those credentials.

An alternative solution would be to configure git-lfs to cache your credentials like so:

git config lfs.cachecredentials true

This will cause git-lfs to cache your credentials for the lifetime of an operation, so you'll only need to enter them once. However, you'll still be prompted for your credentials every time you do a push.

I agree with what @PastelMobileSuit is saying, with this caveat:

From the output, it seems you don't have git setup to store credentials in a credential helper, is that correct? If so, git won't store your credentials, which means git will need to prompt you for them every time git-lfs asks for credentials.

This is the key point. It's normal for Git LFS to need your credentials more than once during an invocation of git-lfs, but your credential helper is what should be hiding that detail from you. That is to say, in normal usage of Git LFS with a configured credential helper, you should not have to enter your credentials more than once (you may not even enter them at all, if they're stored in your Keychain on macOS, or in your ~/.netrc, etc.).

An alternative solution would be to configure git-lfs to cache your credentials like so:

git config lfs.cachecredentials true

This will cause git-lfs to cache your credentials for the lifetime of an operation, so you'll only need to enter them once. However, you'll still be prompted for your credentials every time you do a push.

Completely agree. This is a good way to avoid having to use a credential helper if you for some reason do not want to do so.

Add this to your ~/.ssh/config file.

Host *
  AddKeysToAgent yes
  UseKeychain yes

Start your ssh agent:

eval "$(ssh-agent -s)"

Then add your key:

ssh-add ~/.ssh/id_rsa

note your key could be named differently.

the caching option does sound better. Thanks

Thank you

git config --global lfs.cachecredentials true

Isn't working for me.

git config --global lfs.cachecredentials true worked for me on 2.28.0.windows.1
Don't want to add my key to an agent as I like to control when I'm actually reaching the remote

I can top this behavior by requesting me to type in the password 5 times, tried all of the suggestions in this issue

I can top this behavior by requesting me to type in the password 5 times, tried all of the suggestions in this issue

me too, it was 3 times until today and it has been really annoying

I can top this behavior by requesting me to type in the password 5 times, tried all of the suggestions in this issue

Do you by chance have a security key? I do, and I have to push it 5 times. :(

Do you by chance have a security key? I do, and I have to push it 5 times. :(

Unlike Git, Git LFS uses multiple threads to upload and download data, and as such, it needs an SSH connection for each thread's set of credentials. So multiple SSH connections and multiple uses of the security key are pretty much expected in this case.

For what it's worth, when I ran into this problem today, this comment by @bk2204 from #4060 put me on the right tracks, as it was necessary to both enable git config --global credential.helper cache and unset SSH_ASKPASS, which had been set by Git for Windows OOTB in C:\Program Files\Git\etc\profile.d\env.sh.

I have the same issue with SSH (Ubuntu WSL on Windows) and need to enter my passphrase always 3 times.

For what it's worth, when I ran into this problem today, this comment by @bk2204 from #4060 put me on the right tracks, as it was necessary to both enable git config --global credential.helper cache and unset SSH_ASKPASS, which had been set by Git for Windows OOTB in C:\Program Files\Git\etc\profile.d\env.sh.

I would like to warn from these steps. While the first command had no visible impact, the second simply made git fail to establish connections. 6 retries and then a fail at each push. I solved this with a reinstallation of Git-bash. To confirm this, I tested push after the reinstallation after each of these two commands. After unset, the symptoms started to appear (the 6 retries).

Running into this same issue... I've tried reinstalling to no avail. Asks for my password 5 times - very frustrating

Why is this closed? I shouldn't need a credentials helper or caching of credentials, it should just work like the regular git workflow.

I shouldn't need a credentials helper or caching of credentials, it should just work like the regular git workflow.

The Git client also uses a credentials helper to cache credentials -- that's how it works too. See, for instance, the general Git documentation on credentials and caching, and the documentation on the git credential command.

I shouldn't need a credentials helper or caching of credentials, it should just work like the regular git workflow.

The Git client also uses a credentials helper to cache credentials -- that's how it works too. See, for instance, the general Git documentation on credentials and caching, and the documentation on the git credential command.

It is optional.

Simple example, on a non-lfs repo: 1x touch confirm on my Yubikey for push/pull.

On a lfs repo: 4x touch confirm needed

Just on a surface level as a git user for me this is:

1. Worse experience
2. Using credentials helper is less secure, I want to confirm each action with presence
3. Fundamentally seems like a flawed design.

If you're talking about SSH, then credential helpers are not used at all, even for Git. For most forges, the Git LFS operation actually operates over HTTPS and the SSH key is simply used for authentication. Because the authentication token is time-limited, it may require multiple requests over SSH, which necessarily requires multiple SSH connections.

In either case, Git and Git LFS don't share SSH sessions, nor, for HTTPS, do they share credentials without a credential helper. That's simply not possible and for HTTPS, a credential helper is the official way to share credentials between Git and Git LFS and an important reason for this functionality existing. So if you require interactivity in any way, you are guaranteed to require at least two operations if you're using both Git and Git LFS in the same operation (e.g., git push). Note that partial clone would be even worse in this case. We do have caching for credentials in Git LFS, so users in general should see fewer requests than might otherwise be required, which probably was not implemented as of the original time this issue was opened.

In any event, there are two different issues people are discussing here, which are HTTPS using token authentication and SSH using keys, which are completely different authentication schemes and work completely differently. This is also a closed issue, and I'd like to ask people to honour the contributing documentation and refrain from commenting on closed issues. If you're still seeing a problem, and there is no existing open issue that describes it and is specific to the protocol in question (HTTPS or SSH), then please open a new one, filling out the issue template completely, including reproduction steps, and mentioning the protocol you're using in the title and body of the issue. We'll then look into it and see what we can do to improve things.