git clone via ssh creates wrong .git/config #2761

New Issue

GiteaMirror · 2025-11-02T04:47:15-06:00

GiteaMirror commented

2025-11-02 04:47:15 -06:00

Originally created by @paradoxon82 on GitHub (Jan 16, 2019).

Gitea version (or commit ref): 1.7
Git version: 2.20.1
Operating system: centos 6.10
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:
git clone gitea@hostname:user/NEWTRY.git
...
Error downloading object: CELL1/layout/layout.oa (20d8bba): Smudge error: Error downloading CELL1/layout/layout.oa (20d8bbaa7ef7a354b13d870854453b10ed9cf30b44d8879f8bb0fe34dbd7221e): batch response: Authentication required: Authorization error: http://hostname:3000/user/NEWTRY.git/info/lfs/objects/batch
...

Description

Cloning via ssh fails allways.
When looking into .git/config I see an lfs entry like this:
[lfs "https://hostname/user/NEWTRY.git/info/lfs"]
access = basic
It uses https and port 3000 is missing here, although I configured gitea without https and with port 3000
When I add this line it works:
[lfs]
url = http://hostname:3000/user/NEWTRY.git/info/lfs

Screenshots

Originally created by @paradoxon82 on GitHub (Jan 16, 2019).  - Gitea version (or commit ref): 1.7 - Git version: 2.20.1 - Operating system: centos 6.10 - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: git clone gitea@hostname:user/NEWTRY.git ... Error downloading object: CELL1/layout/layout.oa (20d8bba): Smudge error: Error downloading CELL1/layout/layout.oa (20d8bbaa7ef7a354b13d870854453b10ed9cf30b44d8879f8bb0fe34dbd7221e): batch response: Authentication required: Authorization error: http://hostname:3000/user/NEWTRY.git/info/lfs/objects/batch ... ## Description Cloning via ssh fails allways. When looking into .git/config I see an lfs entry like this: [lfs "https://hostname/user/NEWTRY.git/info/lfs"] access = basic It uses https and port 3000 is missing here, although I configured gitea without https and with port 3000 When I add this line it works: [lfs] url = http://hostname:3000/user/NEWTRY.git/info/lfs ## Screenshots

GiteaMirror added the issue/stale label 2025-11-02 04:47:15 -06:00

GiteaMirror closed this issue

2025-11-02 04:47:16 -06:00

GiteaMirror commented

2025-11-02 04:47:16 -06:00

@ryshi commented on GitHub (Jan 18, 2019):

I have almost the same problem with lfs.
I installed gitea with url https://192.168.1.10/gitea/, pay more attention to /gitea party
My repo's url are

SSH : ssh://git@192.168.1.10:30022/john/lfs.git
HTTPS : https://192.168.1.10/gitea/john/lfs.git

when I clone with ssh url, lfs party of .git/config is

[lfs "https://192.168.1.10/john/lfs.git/info/lfs"]
	locksverify = false

the wired things are

I cloned by ssh, but I got a https url
the url lost /gitea which made lfs works wrong

@ryshi commented on GitHub (Jan 18, 2019): I have almost the same problem with lfs. I installed gitea with url `https://192.168.1.10/gitea/`, pay more attention to `/gitea` party My repo's url are - SSH : `ssh://git@192.168.1.10:30022/john/lfs.git` - HTTPS : `https://192.168.1.10/gitea/john/lfs.git` when I clone with ssh url, lfs party of .git/config is ``` [lfs "https://192.168.1.10/john/lfs.git/info/lfs"] locksverify = false ``` the wired things are 1. I cloned by ssh, but I got a https url 2. the url lost `/gitea` which made lfs works wrong

GiteaMirror commented

2025-11-02 04:47:17 -06:00

@zeripath commented on GitHub (Jan 18, 2019):

Hi @ryshi,

Unfortunately the LFS protocol states that LFS objects are obtained over http/https transport. So getting an https/http URL from ssh is expected.

The loss of the /gitea path component is more suspicious.

Tell me what is your ROOT_URL setting?
Are you definitely SSH cloning as the git user?
If you SSH blindly as your git user, not as part of a git command, just as a normal SSH do you get told Gitea doesn't provide SSH shell access?
Could you check that the git users .ssh/authorized_keys is referencing the correct config file in its commands to Gitea serv.
Have you previously been running Gitea on the root of the server and since then have moved it to the /Gitea suburl?

@zeripath commented on GitHub (Jan 18, 2019): Hi @ryshi, Unfortunately the LFS protocol states that LFS objects are obtained over http/https transport. So getting an https/http URL from ssh is expected. The loss of the `/gitea` path component is more suspicious. * Tell me what is your `ROOT_URL` setting? * Are you definitely SSH cloning as the git user? * If you SSH blindly as your git user, not as part of a git command, just as a normal SSH do you get told Gitea doesn't provide SSH shell access? * Could you check that the git users .ssh/authorized_keys is referencing the correct config file in its commands to Gitea serv. * Have you previously been running Gitea on the root of the server and since then have moved it to the /Gitea suburl?

GiteaMirror commented

2025-11-02 04:47:17 -06:00

@ryshi commented on GitHub (Jan 18, 2019):

Hi @zeripath

So, it should gitea server who give the git client the LFS url to pull objects. I guess if the ROOT_URL was missed there.

I always clone repos via ssh protocol with public/private keys for convenience, so I wanna make it work with LFS.

Tell me what is your ROOT_URL setting? ROOT_URL = https://192.168.1.10/gitea/
Are you definitely SSH cloning as the git user? Yes, I'm running gitea by user git and connect with the key.
If you SSH blindly as your git user, not as part of a git command, just as a normal SSH do you get told Gitea doesn't provide SSH shell access? DISABLE_SSH = false and START_SSH_SERVER = true
Could you check that the git users .ssh/authorized_keys is referencing the correct config file in its commands to Gitea serv. The key works fine without LFS
Have you previously been running Gitea on the root of the server and since then have moved it to the /Gitea suburl? The /gitea was there since gitea was installed and configured

@ryshi commented on GitHub (Jan 18, 2019): Hi @zeripath So, it should gitea server who give the git client the LFS url to pull objects. I guess if the ROOT_URL was missed there. I always clone repos via ssh protocol with public/private keys for convenience, so I wanna make it work with LFS. - Tell me what is your ROOT_URL setting? `ROOT_URL = https://192.168.1.10/gitea/` - Are you definitely SSH cloning as the git user? `Yes, I'm running gitea by user git and connect with the key.` - If you SSH blindly as your git user, not as part of a git command, just as a normal SSH do you get told Gitea doesn't provide SSH shell access? `DISABLE_SSH = false` and `START_SSH_SERVER = true` - Could you check that the git users .ssh/authorized_keys is referencing the correct config file in its commands to Gitea serv. `The key works fine without LFS` - Have you previously been running Gitea on the root of the server and since then have moved it to the /Gitea suburl? `The /gitea was there since gitea was installed and configured`

GiteaMirror commented

2025-11-02 04:47:18 -06:00

@stale[bot] commented on GitHub (Mar 19, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

@stale[bot] commented on GitHub (Mar 19, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

GiteaMirror commented

2025-11-02 04:47:18 -06:00

@stale[bot] commented on GitHub (Apr 2, 2019):

This issue has been automatically closed because of inactivity. You can re-open it if needed.

@stale[bot] commented on GitHub (Apr 2, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror referenced this issue

2025-11-02 12:13:49 -06:00

[PR #2761] [MERGED] Add default ssh ciphers #16576

Sign in to join this conversation.