Wong ssh repository url #1594

New Issue

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

GiteaMirror commented

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

Originally created by @Djang0 on GitHub (Mar 5, 2018).

Gitea version (or commit ref): 1.4
Git version: 2.7.4
Operating system: Ubuntu
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:

Description

Hi,

Very simple problem with a very simple solution. I would then suggest a minor amendment to gitea 1.4.
I have a simple repository that I would clone using ssh. After I created the repository, I can read something like:

...
git remote add origin git@crios-linux:l.reenaers/archive_converter.git
...

I, then, ran :

git clone git@crios-linux:l.reenaers/archive_converter.git

But I got a :

lreenaers@PM-LRE:~/tmp# git clone git@crios-linux:/repositories/l.reenaers/archive_converter.git
Cloning into 'archive_converter'...

Enter passphrase for key '/root/.ssh/id_rsa':
fatal: '/repositories/l.reenaers/archive_converter.git' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

The commande will actually succeed if I write it like that:

lreenaers@PM-LRE:~/tmp# git clone git@crios-linux:gitea/repositories/l.reenaers/archive_converter.git

...

I would kindly suggest that gitea provide user with a correct ssh url, in this case :

git@crios-linux:gitea/repositories/l.reenaers/archive_converter.git

Thanks in advance,

Love Gitea!

Originally created by @Djang0 on GitHub (Mar 5, 2018).  - Gitea version (or commit ref): 1.4 - Git version: 2.7.4 - Operating system: Ubuntu - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description Hi, Very simple problem with a very simple solution. I would then suggest a minor amendment to gitea 1.4. I have a simple repository that I would clone using ssh. After I created the repository, I can read something like: ``` ... git remote add origin git@crios-linux:l.reenaers/archive_converter.git ... ``` I, then, ran : ``` git clone git@crios-linux:l.reenaers/archive_converter.git ``` But I got a : ``` lreenaers@PM-LRE:~/tmp# git clone git@crios-linux:/repositories/l.reenaers/archive_converter.git Cloning into 'archive_converter'... Enter passphrase for key '/root/.ssh/id_rsa': fatal: '/repositories/l.reenaers/archive_converter.git' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ``` The commande will actually succeed if I write it like that: ``` lreenaers@PM-LRE:~/tmp# git clone git@crios-linux:gitea/repositories/l.reenaers/archive_converter.git ``` ... I would kindly suggest that gitea provide user with a correct ssh url, in this case : ``` git@crios-linux:gitea/repositories/l.reenaers/archive_converter.git ``` Thanks in advance, Love Gitea!

GiteaMirror added the type/question label 2025-11-02 04:06:02 -06:00

GiteaMirror closed this issue

2025-11-02 04:06:03 -06:00

GiteaMirror commented

2025-11-02 04:06:03 -06:00

@Djang0 commented on GitHub (Mar 5, 2018):

After commit / push, I can't see any file change in gitea, but files are actually being changed in the repository (file system). But gitea repository still appears empty. I realized that git treated my requests but gitea not aware.

using https made the trick.

@Djang0 commented on GitHub (Mar 5, 2018): After commit / push, I can't see any file change in gitea, but files are actually being changed in the repository (file system). But gitea repository still appears empty. I realized that git treated my requests but gitea not aware. using https made the trick.

GiteaMirror commented

2025-11-02 04:06:03 -06:00

@Adrian-Voelker commented on GitHub (Mar 8, 2018):

Sometimes its also a problem, when two different protocols are stored in the config.
For example:

PROTOCOL = https
ROOT_URL = http:// yourdomain.tld

they should all be the same.

@Adrian-Voelker commented on GitHub (Mar 8, 2018): Sometimes its also a problem, when two different protocols are stored in the config. For example: - PROTOCOL = **https** - ROOT_URL = **http://** yourdomain.tld they should all be the same.

GiteaMirror commented

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

@Djang0 commented on GitHub (Mar 8, 2018):

Anyhow, the ssh url presented in gitea appeared to be incorrect, I don't now why ? using ssh certificates won't work for me... missconfiguration I dont know, but my own is very straight forward...

@Djang0 commented on GitHub (Mar 8, 2018): Anyhow, the ssh url presented in gitea appeared to be incorrect, I don't now why ? using ssh certificates won't work for me... missconfiguration I dont know, but my own is very straight forward...

GiteaMirror commented

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

@techknowlogick commented on GitHub (May 10, 2018):

@Djang0 It could be that gitea isn't handling the SSH connection (by overriding the authorized key file), I have this belief as you are passing a directory in the successful clone, which would be a security issues that gitea would've handled.

@techknowlogick commented on GitHub (May 10, 2018): @Djang0 It could be that gitea isn't handling the SSH connection (by overriding the authorized key file), I have this belief as you are passing a directory in the successful clone, which would be a security issues that gitea would've handled.

GiteaMirror commented

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

@lafriks commented on GitHub (May 10, 2018):

Could it be that you have added your ssh key manually?

@lafriks commented on GitHub (May 10, 2018): Could it be that you have added your ssh key manually?

GiteaMirror commented

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

@Djang0 commented on GitHub (May 11, 2018):

@techknowlogick I don't understand the security issue. Neither what I could do to resolve the situation.

@lafriks I used ssh-copy-id from a mac book pro to upload certificate.

@Djang0 commented on GitHub (May 11, 2018): @techknowlogick I don't understand the security issue. Neither what I could do to resolve the situation. @lafriks I used ssh-copy-id from a mac book pro to upload certificate.

GiteaMirror commented

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

@techknowlogick commented on GitHub (May 11, 2018):

The security issue is that you were able to pass an arbitrary path and were able to get access to that information. To resolve this you'll need to have Gitea manage the authorized key file.

@techknowlogick commented on GitHub (May 11, 2018): The security issue is that you were able to pass an arbitrary path and were able to get access to that information. To resolve this you'll need to have Gitea manage the authorized key file.

GiteaMirror commented

2025-11-02 04:06:05 -06:00

@Djang0 commented on GitHub (May 13, 2018):

The path was not arbitrary and i got an answer because i was authentified by the ssh server through certificates exchange. So I think this was a normal behaviour. Wasn't it?

@Djang0 commented on GitHub (May 13, 2018): The path was not arbitrary and i got an answer because i was authentified by the ssh server through certificates exchange. So I think this was a normal behaviour. Wasn't it?

GiteaMirror commented

2025-11-02 04:06:05 -06:00

@techknowlogick commented on GitHub (May 16, 2018):

A user in the forum is experiencing the same issue as you, and @daviian wrote a better reply to them than I did to you, so I'll copy it here (source: https://discourse.gitea.io/t/using-regular-git-ssh-not-working/286/2 )

Hi,

To clarify the SSH url: the stuff after the colon is for internal use in gitea. Gitea itself provides the mapping to the actual repository location.
So what you do when using the original path is bypassing gitea, which shouldn’t be possible at all!

One reason this happens is that you set your SSH key in the authorized_keys file yourself with e.g. ssh-copy-id. However that’s wrong and you should definitely let gitea handle this file.
Furthermore everytime a user adds an SSH key via gitea web-UI the authorized_keys file gets overwritten.

Another thing is that usually the user from the SSH url is git or whatever is configured in the app.ini and not the actual gitea-user itself.

The first thing you should try now is to go into the Admin settings on the gitea UI and execute:

Update the ‘.ssh/authorized_keys’ file with Gitea SSH keys. (Not needed for the built-in SSH server.)
Resynchronize pre-receive, update and post-receive hooks of all repositories.

After that you HAVE to set your SSH keys through gitea web-UI.

Hopefully that solves your issue!

@techknowlogick commented on GitHub (May 16, 2018): A user in the forum is experiencing the same issue as you, and @daviian wrote a better reply to them than I did to you, so I'll copy it here (source: https://discourse.gitea.io/t/using-regular-git-ssh-not-working/286/2 ) ----- Hi, To clarify the SSH url: the stuff after the colon is for internal use in gitea. Gitea itself provides the mapping to the actual repository location. So what you do when using the original path is bypassing gitea, which shouldn’t be possible at all! One reason this happens is that you set your SSH key in the authorized_keys file yourself with e.g. ssh-copy-id. However that’s wrong and you should definitely let gitea handle this file. Furthermore everytime a user adds an SSH key via gitea web-UI the authorized_keys file gets overwritten. Another thing is that usually the user from the SSH url is git or whatever is configured in the app.ini and not the actual gitea-user itself. The first thing you should try now is to go into the Admin settings on the gitea UI and execute: 1. Update the ‘.ssh/authorized_keys’ file with Gitea SSH keys. (Not needed for the built-in SSH server.) 2. Resynchronize pre-receive, update and post-receive hooks of all repositories. After that you HAVE to set your SSH keys through gitea web-UI. Hopefully that solves your issue!

GiteaMirror commented

2025-11-02 04:06:05 -06:00

@Djang0 commented on GitHub (May 17, 2018):

Thank you @techknowlogick ! It is now very clear to me.

@Djang0 commented on GitHub (May 17, 2018): Thank you @techknowlogick ! It is now very clear to me.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#1594