Using with GitHub - How to get either SSH or HTTPS to work?

[SnapperTT]

Hi all,

I have a new machine with a fresh install of arch-linux, git and a git-lfs. I have copied my ~/.ssh folder from my old machine to my new machine. ssh works as expected.

git clone git@github.com:SnapperTT/XXXX works as expected, but the lfs files are not fetched
git lfs ls-files returns the expected result
git lfs pull fails silently

Here is the output of GIT_TRACE=1 GIT_TRANSFER_TRACE=1 GIT_CURL_VERBOSE=1 git lfs pull 2>&1 | tee gitlfspull.log

23:48:55.473797 git.c:775               trace: exec: git-lfs pull
23:48:55.473847 run-command.c:673       trace: run_command: git-lfs pull
23:48:55.473869 run-command.c:765       trace: start_command: /usr/bin/git-lfs pull
23:48:55.487301 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' '--git-dir' '--show-toplevel'
23:48:55.489286 trace git-lfs: exec: git 'rev-parse' '--is-bare-repository'
23:48:55.491106 trace git-lfs: exec: git 'config' '--includes' '--local' 'lfs.repositoryformatversion'
23:48:55.493004 trace git-lfs: exec: git 'config' '--includes' '-l'
23:48:55.494758 trace git-lfs: exec: git 'rev-parse' '--is-bare-repository'
23:48:55.496759 trace git-lfs: exec: git 'config' '--includes' '-l' '--blob' ':.lfsconfig'
23:48:55.498965 trace git-lfs: exec: git 'config' '--includes' '-l' '--blob' 'HEAD:.lfsconfig'
23:48:55.502212 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'
23:48:55.504539 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'
23:48:55.506507 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' '--git-dir'
23:48:55.508409 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'remote'
23:48:55.510528 trace git-lfs: tq: running as batched queue, batch size of 100
23:48:55.510683 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'ls-files' '--cached' '--exclude-standard' '--full-name' '--sparse' '-z' '--format=%(objectmode) %(objecttype) %(objectname) %(objectsize)	%(path)' ':(top,attr:filter=lfs)'
23:48:55.511172 trace git-lfs: exec: git '-c' 'filter.lfs.smudge=' '-c' 'filter.lfs.clean=' '-c' 'filter.lfs.process=' '-c' 'filter.lfs.required=false' 'rev-parse' '--git-common-dir'
23:48:55.513805 trace git-lfs: filepathfilter: accepting "(REDACTED 1)"
23:48:55.513882 trace git-lfs: filepathfilter: accepting "(REDACTED 2)"
23:48:55.513893 trace git-lfs: filepathfilter: accepting "(REDACTED 3)"
23:48:55.513899 trace git-lfs: filepathfilter: accepting "(REDACTED 4)"
23:48:55.513905 trace git-lfs: filepathfilter: accepting "(REDACTED 5)"
23:48:55.513910 trace git-lfs: filepathfilter: accepting "(REDACTED 6)"
23:48:55.513916 trace git-lfs: filepathfilter: accepting "(REDACTED 7)"
23:48:55.513921 trace git-lfs: filepathfilter: accepting "(REDACTED 8)"
23:48:55.513927 trace git-lfs: filepathfilter: accepting "(REDACTED 9)"
23:48:55.513936 trace git-lfs: filepathfilter: accepting "(REDACTED 10)"
23:48:55.513941 trace git-lfs: filepathfilter: accepting "(REDACTED 11)"
23:48:55.513946 trace git-lfs: filepathfilter: accepting "(REDACTED 12)"
23:48:55.513951 trace git-lfs: filepathfilter: accepting "(REDACTED 13)"
23:48:55.513956 trace git-lfs: filepathfilter: accepting "(REDACTED 14)"
23:48:55.513961 trace git-lfs: filepathfilter: accepting "(REDACTED 15)"
23:48:55.517086 trace git-lfs: attempting pure SSH protocol connection (download, origin)
23:48:55.517105 trace git-lfs: spawning pure SSH connection (#0)
23:48:55.517205 trace git-lfs: run_command: ssh -oControlMaster=yes -oControlPath=/run/user/1000/sock-1709785463/lfs.sock git@github.com git-lfs-transfer SnapperTT/XXXX download
23:48:55.517314 trace git-lfs: exec: ssh '-oControlMaster=yes' '-oControlPath=/run/user/1000/sock-1709785463/lfs.sock' 'git@github.com' 'git-lfs-transfer SnapperTT/XXXX download'
23:48:58.151628 trace git-lfs: pure SSH connection unsuccessful (#0)
23:48:58.151647 trace git-lfs: pure SSH protocol connection failed (download, origin): Unable to negotiate version with remote side (unable to read capabilities): EOF
Failed to connect to remote SSH server: Invalid command: git-lfs-transfer SnapperTT/XXXX download
  You appear to be using ssh to clone a git:// URL.
  Make sure your core.gitProxy config option and the
  GIT_PROXY_COMMAND environment variable are NOT set.

23:48:58.151927 trace git-lfs: filepathfilter: creating pattern ".git" of type gitignore
23:48:58.151947 trace git-lfs: filepathfilter: creating pattern "**/.git" of type gitignore
23:48:58.152008 trace git-lfs: filepathfilter: accepting "tmp"

GIT_PROXY_COMMAND is unset.
git config core.gitProxy is blank.

I've been googling and chatgpt-ing around, many sources say that github does not support git-lfs over ssh, but the sources are at least 5 years old. Does github support git-lfs over ssh in 2025? What is currently the best practice?

My old machine is running git-lfs 2.7.1, it can push and pull okay. Using GIT_TRACE=1 reveals that it is using https.

I have tried switching to https to download the files but it appears that git-lfs ignores anything I throw at it.

Here is my current .gitconfig

[user]
	email = REDACTED
	name = REDACTED
[filter "lfs"]
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge -- %f
	process = git-lfs filter-process
	required = true
[url "ssh://git@github.com/"]
	insteadOf = https://github.com/
[lfs]
	gitprotocol = https
[credential]
	helper = cache

Here is the output of git lfs env:

 git-lfs/3.7.0 (GitHub; linux amd64; go 1.24.5)
git version 2.51.0

Endpoint=https://github.com/SnapperTT/XXXX.git/info/lfs (auth=none)
  SSH=git@github.com:SnapperTT/XXXX
LocalWorkingDir=/home/snappertt/XXXX
LocalGitDir=/home/snappertt/XXXX/.git
LocalGitStorageDir=/home/snappertt/XXXX/.git
LocalMediaDir=/home/snappertt/XXXX/.git/lfs/objects
LocalReferenceDirs=
TempDir=/home/snappertt/XXXX/.git/lfs/tmp
ConcurrentTransfers=8
TusTransfers=false
BasicTransfersOnly=false
SkipDownloadErrors=false
FetchRecentAlways=false
FetchRecentRefsDays=7
FetchRecentCommitsDays=0
FetchRecentRefsIncludeRemotes=true
PruneOffsetDays=3
PruneVerifyRemoteAlways=false
PruneVerifyUnreachableAlways=false
PruneRemoteName=origin
LfsStorageDir=/home/snappertt/XXXX/.git/lfs
AccessDownload=none
AccessUpload=none
DownloadTransfers=basic,lfs-standalone-file,ssh
UploadTransfers=basic,lfs-standalone-file,ssh
GIT_EXEC_PATH=/usr/lib/git-core
git config filter.lfs.process = "git-lfs filter-process"
git config filter.lfs.smudge = "git-lfs smudge -- %f"
git config filter.lfs.clean = "git-lfs clean -- %f"

[chrisd8088]

Hey, thanks for the question, and I'm sorry you're having trouble.

I think the short version of my answer below is that you should check whether you have a .gitattributes file in your repository and if it has filter=lfs lines for all the file patterns you expect to be treated as Git LFS files. Without those in place, recent versions of the git lfs pull command will not find Git LFS files and fetch their objects.

If you do have a .gitattributes in your branch's HEAD, you could use the git check-attr command to see if a file you expect to be a Git LFS file actually matches a filter=lfs attribute. Here's a quick example of what that should look like, with a single filter=lfs pattern for *.bin files:

$ git show HEAD:.gitattributes
*.bin filter=lfs diff=lfs merge=lfs -text

$ git check-attr -a foo.bin
foo.bin: diff: lfs
foo.bin: merge: lfs
foo.bin: text: unset
foo.bin: filter: lfs

---

So far as I know, GitHub does not support the "pure" SSH-only Git LFS transfer protocol yet, which the Git LFS client began to support with our v3.0.0 release. That's the reason you see in your Git LFS trace logs the client trying to run the git-lfs-transfer SnapperTT/XXXX download SSH command, to check whether the remote server supports this Git LFS protocol or not.

However, GitHub does support the SSH authentication mechanism for Git LFS, by which the client authenticates over SSH, but is then redirected to use HTTPS for the actual Git LFS Batch API requests and object transfer requests. By default, the Git LFS client will fall back to trying this technique if the server doesn't support the "pure" SSH-only Git LFS protocol.

If that was happening, it would appear in your trace logs as an attempt by the client to run the git-lfs-authenticate SnapperTT/XXXX download command, to which GitHub should reply and you'd then start seeing requests like POST https://lfs.github.com/SnapperTT/XXXX/objects/batch.

I just re-tested this behaviour with one of my own GitHub repositories and it works as expected for me.

If you had lfs.sshTransfer set to always, that would cause the Git LFS client to not proceed to the git-lfs-authenticate fallback technique, but then I'd expect to see git-lfs-authenticate has been disabled by request in your trace logs. Since that's not what you're seeing, I think there may be another problem, as described below.

If you do encounter specific problems with GitHub's SSH services, though, you should reach out via GitHub's Support site for help, as this project is only for the open-source Git LFS client.

---

Putting SSH issues aside, the fact that you're seeing no fetch: <file path> entries in your trace logs and that git clone is also not fetching anything makes me wonder if by chance your repository is missing the appropriate filter=lfs settings in .gitattributes for your Git LFS files, similar to the problem described in #6061.

Beginning with Git LFS v3.6.0, the changes from PR #5699 mean that git lfs pull will use the output from a specialized git ls-files command to determine which Git LFS files, if any, exist in the current revision. This command depends on a valid filter=lfs Git attribute to match the files. Likewise, git clone will only invoke the Git LFS client for files which match a filter=lfs attribute, at which point the Git LFS client will retrieve the object data as necessary to smudge the files.

But the git lfs ls-files command still depends on the git ls-tree command and then just looks for files in the tree which are formatted as Git LFS pointers, regardless of whether those files match a filter=lfs attribute.

In a normal test repository cloned from GitHub with a Git LFS file named foo.bin and a corresponding line in the .gitattributes file, if I run the following commands then the trace log from the final git lfs pull command matches yours in that I see the git-lfs-transfer attempt (where the client is probing to see if GitHub supports the "pure" SSH transfer protocol) and then no actual fetch actions.

$ git rm .gitattributes
$ git commit -m "remove LFS filter attributes"

$ rm -rf * .git/lfs/objects

$ git lfs ls-files
b5bb9d8014 - foo.bin

$ GIT_TRACE=1 git lfs pull
# no output and foo.bin not fetched

Given how closely my trace log matches yours in this scenario, I suspect you have a similar situation, where you were still able to fetch Git LFS objects with the client prior to v3.6.0 by running git lfs pull, even if git clone didn't do this because the Git LFS smudge filter was never invoked, but now neither git clone nor git lfs pull will succeed.

[SnapperTT]

Good spot with the .gitattributes file. It was including some files but not others. To get it to work, I had to update the .gitattributes file on the old machine, commit, push, and on the new machine git clone just worked.

Thanks for your help and your speedy response, cheers mate!