Cloning over SSH won't work #584

New Issue

GiteaMirror · 2025-11-02T03:28:57-06:00

GiteaMirror commented

2025-11-02 03:28:57 -06:00

Originally created by @rolandplanitz on GitHub (Mar 28, 2017).

Gitea version (or commit ref): 1.1.0+75-g6a451a2
Git version: git version 2.7.4
Operating system: CentOS 6
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

I just switched from Gitlab to Gitea and first I worked with the https links to clone/push my repositories which works just fine.

Then I generated a SSH Keyfile which I uploaded in the profile but now I get this error:

[roland@Black-Devil:~] % git clone gitlab@gitlab.planitz.at:evil_corp/testingtesing.git teaS
Cloning into 'teaS'...
GitLab: API is not accessible
fatal: Could not read from remote repository.

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

The log in the console gives me the following:

$ gitea web
2017/03/28 18:18:04 [T] Custom path: /home/gitlab/src/go/src/code.gitea.io/gitea/custom
2017/03/28 18:18:04 [T] Log path: /home/gitlab/src/go/src/code.gitea.io/gitea/log
2017/03/28 18:18:05 Serving [::]:9765 with pid 6030
[Macaron] 2017-03-28 18:18:08: Started POST /api/v3/internal/allowed for 95.143.172.134, 95.143.172.134
[Macaron] 2017-03-28 18:18:08: Completed /api/v3/internal/allowed 404 Not Found in 8.353938ms

Originally created by @rolandplanitz on GitHub (Mar 28, 2017). - Gitea version (or commit ref): 1.1.0+75-g6a451a2 - Git version: `git version 2.7.4` - Operating system: CentOS 6 - 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 I just switched from Gitlab to Gitea and first I worked with the https links to clone/push my repositories which works just fine. Then I generated a SSH Keyfile which I uploaded in the profile but now I get this error: ``` [roland@Black-Devil:~] % git clone gitlab@gitlab.planitz.at:evil_corp/testingtesing.git teaS Cloning into 'teaS'... GitLab: API is not accessible fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ``` The log in the console gives me the following: ``` $ gitea web 2017/03/28 18:18:04 [T] Custom path: /home/gitlab/src/go/src/code.gitea.io/gitea/custom 2017/03/28 18:18:04 [T] Log path: /home/gitlab/src/go/src/code.gitea.io/gitea/log 2017/03/28 18:18:05 Serving [::]:9765 with pid 6030 [Macaron] 2017-03-28 18:18:08: Started POST /api/v3/internal/allowed for 95.143.172.134, 95.143.172.134 [Macaron] 2017-03-28 18:18:08: Completed /api/v3/internal/allowed 404 Not Found in 8.353938ms ```

GiteaMirror added the type/question label 2025-11-02 03:28:57 -06:00

GiteaMirror closed this issue

2025-11-02 03:28:57 -06:00

GiteaMirror commented

2025-11-02 03:28:58 -06:00

@lunny commented on GitHub (Mar 29, 2017):

I think you can take a look your auth file to confirm your public key has been written to.
The returned message GitLab: API is not accessible is from GitLab.

@lunny commented on GitHub (Mar 29, 2017): I think you can take a look your auth file to confirm your public key has been written to. The returned message `GitLab: API is not accessible` is from GitLab.

GiteaMirror commented

2025-11-02 03:28:58 -06:00

@rolandplanitz commented on GitHub (Mar 29, 2017):

Thanks for the quick response. It was indead some rest of gitlab.
Now I uninstalled gitlab completely and have another problem.

When I let gitea build the .ssh/authorized_keys file It destroys my ssh key that I need to connect to the server which is kind of bad ;)

In that situation connecting via SSH shows the expected message that I'm authenticated but have no shell. Cloning works as well.

I tried the following setting in my /custom/conf/app.ini:
SSH_ROOT_PATH = /home/gitlab/.gitea Yes I know it is confusing but my user is called gitlab and I cannot change it at the moment)

This won't work. ssh -v shows me that the authorization via the public key fails.

@rolandplanitz commented on GitHub (Mar 29, 2017): Thanks for the quick response. It was indead some rest of gitlab. Now I uninstalled gitlab completely and have another problem. When I let gitea build the .ssh/authorized_keys file It destroys my ssh key that I need to connect to the server which is kind of bad ;) In that situation connecting via SSH shows the expected message that I'm authenticated but have no shell. Cloning works as well. I tried the following setting in my /custom/conf/app.ini: `SSH_ROOT_PATH = /home/gitlab/.gitea` Yes I know it is confusing but my user is called gitlab and I cannot change it at the moment) This won't work. ssh -v shows me that the authorization via the public key fails.

GiteaMirror commented

2025-11-02 03:28:58 -06:00

@lunny commented on GitHub (Mar 30, 2017):

destroy non-gitea ssh key has been resolved by #906

@lunny commented on GitHub (Mar 30, 2017): `destroy non-gitea ssh key` has been resolved by #906

GiteaMirror commented

2025-11-02 03:28:58 -06:00

@rolandplanitz commented on GitHub (Mar 30, 2017):

well the Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys) operation from the Admin Dashboard still kills everything else in authorized_keys which got me into this situation in the first place.

Fortunately my hoster can write my public key into that file as well.
But this key gets written below the already existing gitea key. And that combination does not work at all.

This was my workflow now (all working just fine)

delete .ssh/authorized_key
let my hoster write the public key to connect to the server itself
go to user settings in gitea
remove the ssh key
re add the same ssh key (that seems to trigger a non destroying write process)

Now the .ssh/authorized_keys file has my public key for the machine on top and the gitea public key below which works for both connections (to the machine as well as to the gitea instance)

@rolandplanitz commented on GitHub (Mar 30, 2017): well the `Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys)` operation from the Admin Dashboard still kills everything else in authorized_keys which got me into this situation in the first place. Fortunately my hoster can write my public key into that file as well. But this key gets written below the already existing gitea key. And that combination does not work at all. This was my workflow now (all working just fine) * delete `.ssh/authorized_key` * let my hoster write the public key to connect to the server itself * go to user settings in gitea * remove the ssh key * re add the same ssh key (that seems to trigger a non destroying write process) Now the `.ssh/authorized_keys` file has my public key for the machine on top and the gitea public key below which works for both connections (to the machine as well as to the gitea instance)

GiteaMirror commented

2025-11-02 03:28:58 -06:00

@lunny commented on GitHub (Mar 30, 2017):

@@For a normal use, we use user git which should not login always, so that file should only have gitea's public keys. We can create another user to access the host via SSH and sudo su git to operate as git user.

@lunny commented on GitHub (Mar 30, 2017): @@For a normal use, we use user `git` which should not login always, so that file should only have gitea's public keys. We can create another user to access the host via SSH and `sudo su git` to operate as `git` user.

GiteaMirror commented

2025-11-02 03:28:59 -06:00

@rolandplanitz commented on GitHub (Mar 30, 2017):

sounds reasonable with my hoster however I got only one user, therefore that's not possible.

@rolandplanitz commented on GitHub (Mar 30, 2017): sounds reasonable with my hoster however I got only one user, therefore that's not possible.

GiteaMirror commented

2025-11-02 03:28:59 -06:00

@lunny commented on GitHub (Mar 31, 2017):

So maybe you can use different public key and It's strange that the latest Gitea should keep yourself public key when rewrite Gitea's.

@lunny commented on GitHub (Mar 31, 2017): So maybe you can use different public key and It's strange that the latest Gitea should keep yourself public key when rewrite Gitea's.

GiteaMirror commented

2025-11-02 03:28:59 -06:00

@rolandplanitz commented on GitHub (Mar 31, 2017):

Hi,

as I wrote above when my public key for the server (different from the public key for gitea) is in the authorized_keys file before I add ssh keys to gitea everything works fine.

the rewrite button in the admin dashboard however kills the whole authorized_key file and only adds gitea ssh keys.

@rolandplanitz commented on GitHub (Mar 31, 2017): Hi, as I wrote above when my public key for the server (different from the public key for gitea) is in the authorized_keys file before I add ssh keys to gitea everything works fine. the rewrite button in the admin dashboard however kills the whole authorized_key file and only adds gitea ssh keys.

GiteaMirror commented

2025-11-02 03:28:59 -06:00

@strk commented on GitHub (Apr 1, 2017):

What version of Gitea are you using ? Because I thought this was
fixed with 4c12e2a4b9 by @lunny

@strk commented on GitHub (Apr 1, 2017): What version of Gitea are you using ? Because I thought this was fixed with 4c12e2a4b90237a8687b497ae14a402346b0406d by @lunny

GiteaMirror commented

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

@rolandplanitz commented on GitHub (Apr 2, 2017):

1.1.0+75-g6a451a2

@rolandplanitz commented on GitHub (Apr 2, 2017): 1.1.0+75-g6a451a2

GiteaMirror commented

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

@lafriks commented on GitHub (Jun 5, 2018):

Closing as answered, please reopen if issue persists

@lafriks commented on GitHub (Jun 5, 2018): Closing as answered, please reopen if issue persists

GiteaMirror commented

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

@kiemrong08 commented on GitHub (Jul 23, 2018):

I faced this problem and resolve this.
I has made mistake when config user in gitea.service file in systemd is root and config .ssh directory of user git in app.ini like SSH_ROOT_PATH = /home/git/.ssh/gitea.
i changed this user in gitea.service to git and SSH_ROOT_PATH = /home/git/.ssh then go to admin dasboard and press to Update the '.ssh/authorized_keys' file with Gitea SSH keys.
After previous action, i can git clone over SSH like normal. it's worked like a charm. Dont forget set 755 permission to .ssh folder and 600 to authorized_keys and don't edit authorized_keys file by editor and insert rsa key manually, you must open web-UI and copy key of local and paste to SSH / GPG Keys in Settings of your gitea account. And dont add key to file authorized_keys in .ssh folder of system user git to config password-less login ssh. When config successfully, if you try ssh to git account you will see the message like this:

ssh git@10.10.42.251
PTY allocation request failed on channel 0
Hi there, You've successfully authenticated, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.
Connection to 10.10.42.251 closed.

@kiemrong08 commented on GitHub (Jul 23, 2018): I faced this problem and resolve this. I has made mistake when config user in `gitea.service` file in systemd is `root` and config `.ssh` directory of user `git` in `app.ini` like `SSH_ROOT_PATH = /home/git/.ssh/gitea`. i changed this user in `gitea.service` to `git` and `SSH_ROOT_PATH = /home/git/.ssh` then go to admin dasboard and press to **Update the '.ssh/authorized_keys' file with Gitea SSH keys**. After previous action, i can `git clone` over SSH like normal. it's worked like a charm. Dont forget set `755` permission to `.ssh` folder and `600` to `authorized_keys` and don't edit `authorized_keys` file by editor and insert rsa key manually, you must open web-UI and copy key of local and paste to `SSH / GPG Keys` in `Settings` of your `gitea` account. And dont add key to file `authorized_keys` in `.ssh` folder of system user `git` to config password-less login `ssh`. When config successfully, if you try `ssh` to `git` account you will see the message like this: ``` ssh git@10.10.42.251 PTY allocation request failed on channel 0 Hi there, You've successfully authenticated, but Gitea does not provide shell access. If this is unexpected, please log in with password and setup Gitea under another user. Connection to 10.10.42.251 closed. ```

GiteaMirror referenced this issue

2025-11-02 11:47:14 -06:00

[PR #584] [MERGED] Fix diff split view coloring being solid color for the whole row (#553) #15469

GiteaMirror referenced this issue

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

[PR #585] [MERGED] Fix unified diff view styling #15470

Sign in to join this conversation.