github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-12 02:24:21 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Permission denied (publickey) #1083

New Issue
Closed
opened 2025-11-02 03:47:42 -06:00 by GiteaMirror · 7 comments
GiteaMirror commented 2025-11-02 03:47:42 -06:00
Owner
Copy Link

Originally created by @axeloz on GitHub (Sep 20, 2017).

  • Gitea version (or commit ref): 1.2.0+rc2
  • Git version: 1.9.1
  • Operating system: Ubuntu 14LTS
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant

Description

Hello,

I'm not sure whether this is an issue or just a support request. I have a problem accessing my Gitea sources using SSH. I get a "Permission denied (publickey)" error when issuing a git pull command on an existing repository.

On my Mac, I have my own user with my SSH key pair. My public key is set on my Gitea account.
From my Mac, I may git clone, no problem at all. But when I login via SSH to a distant server (to my Vagrant, to any of my distant dedicated servers, ...), I cannot git pull any longer.
However the SSH identity forwarding is enabled for all these servers and it's working, I have checked doing a: echo "$SSH_AUTH_SOCK".

The problem is that it used to work prior to upgrading Gitea to 1.2.0+rc2. I really don't understand why this should have any impact on an SSH authentication mechanism but I thought it'd be best to talk to you guys about this. The point is that I find this confusing that it occurs on all distant servers (not only one). I don't think this is a server related configuration issue as I didn't touch anything there.

I could not find anything interesting in the logs. Actually, I even did a multitail *.log on Gitea, I tried to git pull but no line, not even one, was appended to the output.

I know what you will answer to me, you will ask me to downgrade but I'm not very confident with downgrading on a PROD application.

If you have any idea...
Thanks

Screenshots

Originally created by @axeloz on GitHub (Sep 20, 2017). - Gitea version (or commit ref): 1.2.0+rc2 - Git version: 1.9.1 - Operating system: Ubuntu 14LTS - 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 ## Description Hello, I'm not sure whether this is an issue or just a support request. I have a problem accessing my Gitea sources using SSH. I get a "Permission denied (publickey)" error when issuing a `git pull` command on an existing repository. On my Mac, I have my own user with my SSH key pair. My public key is set on my Gitea account. From my Mac, I may `git clone`, no problem at all. But when I login via SSH to a distant server (to my Vagrant, to any of my distant dedicated servers, ...), I cannot `git pull` any longer. However the SSH identity forwarding is enabled for all these servers and it's working, I have checked doing a: `echo "$SSH_AUTH_SOCK"`. The problem is that **it used to work prior to upgrading Gitea** to 1.2.0+rc2. I really don't understand why this should have any impact on an SSH authentication mechanism but I thought it'd be best to talk to you guys about this. The point is that I find this confusing that it occurs on all distant servers (not only one). I don't think this is a server related configuration issue as I didn't touch anything there. I could not find anything interesting in the logs. Actually, I even did a `multitail *.log` on Gitea, I tried to `git pull` but no line, not even one, was appended to the output. I know what you will answer to me, you will ask me to downgrade but I'm not very confident with downgrading on a PROD application. If you have any idea... Thanks ## Screenshots
GiteaMirror added the type/question label 2025-11-02 03:47:42 -06:00
GiteaMirror commented 2025-11-02 03:47:42 -06:00
Author
Owner
Copy Link

@axeloz commented on GitHub (Sep 20, 2017):

FYI, I don't use Gitea's builtin SSH:

; Whether use builtin SSH server or not.
START_SSH_SERVER       = false

Also, in /var/log/auth.log, here is what I get (in DEBUG mode) when I git pull:

Sep 20 10:26:10 new sshd[1161]: debug1: Forked child 19104.
Sep 20 10:26:10 new sshd[19104]: Set /proc/self/oom_score_adj to 0
Sep 20 10:26:10 new sshd[19104]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Sep 20 10:26:10 new sshd[19104]: debug1: inetd sockets after dupping: 3, 3
Sep 20 10:26:10 new sshd[19104]: Connection from XXX.XXX.206.160 port 61520 on XXX.XXX.249.153 port 22
Sep 20 10:26:10 new sshd[19104]: debug1: Client protocol version 2.0; client software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
Sep 20 10:26:10 new sshd[19104]: debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x04000000
Sep 20 10:26:10 new sshd[19104]: debug1: Enabling compatibility mode for protocol 2.0
Sep 20 10:26:10 new sshd[19104]: debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8
Sep 20 10:26:10 new sshd[19104]: debug1: permanently_set_uid: 105/65534 [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: SSH2_MSG_KEXINIT received [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: KEX done [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: userauth-request for user git service ssh-connection method none [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: attempt 0 failures 0 [preauth]
Sep 20 10:26:10 new sshd[19104]: Connection closed by XXX.XXX.206.160 [preauth]

I tried to regenerate the .ssh/authorized_keys from Gitea but that didn't fix.

@axeloz commented on GitHub (Sep 20, 2017): FYI, I don't use Gitea's builtin SSH: ``` ; Whether use builtin SSH server or not. START_SSH_SERVER = false ``` Also, in /var/log/auth.log, here is what I get (in DEBUG mode) when I git pull: ``` Sep 20 10:26:10 new sshd[1161]: debug1: Forked child 19104. Sep 20 10:26:10 new sshd[19104]: Set /proc/self/oom_score_adj to 0 Sep 20 10:26:10 new sshd[19104]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 Sep 20 10:26:10 new sshd[19104]: debug1: inetd sockets after dupping: 3, 3 Sep 20 10:26:10 new sshd[19104]: Connection from XXX.XXX.206.160 port 61520 on XXX.XXX.249.153 port 22 Sep 20 10:26:10 new sshd[19104]: debug1: Client protocol version 2.0; client software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 Sep 20 10:26:10 new sshd[19104]: debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x04000000 Sep 20 10:26:10 new sshd[19104]: debug1: Enabling compatibility mode for protocol 2.0 Sep 20 10:26:10 new sshd[19104]: debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8 Sep 20 10:26:10 new sshd[19104]: debug1: permanently_set_uid: 105/65534 [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: SSH2_MSG_KEXINIT sent [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: SSH2_MSG_KEXINIT received [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: SSH2_MSG_NEWKEYS sent [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: expecting SSH2_MSG_NEWKEYS [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: SSH2_MSG_NEWKEYS received [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: KEX done [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: userauth-request for user git service ssh-connection method none [preauth] Sep 20 10:26:10 new sshd[19104]: debug1: attempt 0 failures 0 [preauth] Sep 20 10:26:10 new sshd[19104]: Connection closed by XXX.XXX.206.160 [preauth] ``` I tried to regenerate the .ssh/authorized_keys from Gitea but that didn't fix.
GiteaMirror commented 2025-11-02 03:47:43 -06:00
Author
Owner
Copy Link

@axeloz commented on GitHub (Sep 22, 2017):

Hello,

Still stuck on this one. Has anyone got the chance to look at this?
Thanks

@axeloz commented on GitHub (Sep 22, 2017): Hello, Still stuck on this one. Has anyone got the chance to look at this? Thanks
GiteaMirror commented 2025-11-02 03:47:43 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Sep 22, 2017):

ssh -vvv git@github.com maybe you can debug the ssh

@lunny commented on GitHub (Sep 22, 2017): `ssh -vvv git@github.com` maybe you can debug the ssh
GiteaMirror commented 2025-11-02 03:47:43 -06:00
Author
Owner
Copy Link

@realholgi commented on GitHub (Jan 11, 2018):

I had the same problem. It is a permission problem on the server in at least your .ssh directory. It has to belong to the gitea service owner. I my case it was root, because fro trying out gitea I ran it as root (!).

@realholgi commented on GitHub (Jan 11, 2018): I had the same problem. It is a permission problem on the server in at least your .ssh directory. It has to belong to the gitea service owner. I my case it was root, because fro trying out gitea I ran it as root (!).
GiteaMirror commented 2025-11-02 03:47:43 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 12, 2018):

I am having the same issue since gitea v1.3.1 I think, now I am on v1.3.3.

For some reason, whenever I recreate a gitea container in my Kubernetes environment, it adds group-write permissions to the .ssh/ and .ssh/authorized_keys:

gitea-server # ls -lad /data/git/.ssh/authorized_keys /data/git/.ssh /data/git /data /
drwxr-xr-x    1 root     root            62 Mar 12 08:27 /
drwxrwsr-x    5 git      bin           4096 Aug 25  2017 /data
drwxr-xr-x    4 git      git           4096 Mar 12 08:27 /data/git
drwxrwS---    2 git      git           4096 Jan 22 22:38 /data/git/.ssh
-rw-rw----    1 git      git           2370 Mar  1 07:58 /data/git/.ssh/authorized_keys

My persistent volume is mounted over /data.

The symptoms are the following:

client $ ssh -p10022 -T git@mygitea.com
Permission denied (publickey).

In the gitea logs:

Mar 12 08:18:50 sshd[31]: Authentication refused: bad ownership or modes for file /data/git/.ssh/authorized_keys
Mar 12 08:18:50 sshd[31]: Connection closed by authenticating user git 10.37.64.0 port 36752 [preauth]

As a workaround I am removing write permissions from the group and removing others from rwx each time I recreate the Gitea container:

gitea-server # chmod g-w,o= /data/git/.ssh/authorized_keys /data/git/.ssh

Update

I have just tested this with docker on my laptop and I was unable to reproduce the same:

docker run --rm -ti -p 10022:22 -p 3000:3000 -v /tmp/vol:/data gitea/gitea:1.3.3

gitea-v1.3.3 in a docker # ls -lad /data/git/.ssh/authorized_keys /data/git/.ssh /data/git /data 
drwxr-xr-x    1 root     root          4096 Mar 12 08:50 /
drwxr-xr-x    5 root     root          4096 Mar 12 08:43 /data
drwxr-xr-x    4 git      git           4096 Mar 12 08:50 /data/git
drwx------    2 git      git           4096 Mar 12 08:50 /data/git/.ssh
-rw-------    1 git      git            905 Mar 12 08:50 /data/git/.ssh/authorized_keys

There must be something wrong with my volume as I was trying to mount it to /data under a different image and the data got setgid and group rwx again. Which is pretty strange on its own.

Update 2

Okay, my issue was solely due to the Kubernetes's fsGroup parameter that I was using (set either via securityContext or a PodSecurityPolicy MustRunAs). It was making dirs/files permissions in volumes always get reset to 770/660 whenever POD is recreated with fsGroup used.
One may either not use the fsGroup at all or as a workaround - change permissions right after the container is started, e.g. https://github.com/kubernetes/kubernetes/issues/2630#issuecomment-321009380

@ghost commented on GitHub (Mar 12, 2018): I am having the same issue since gitea v1.3.1 I think, now I am on v1.3.3. For some reason, whenever I recreate a gitea container in my Kubernetes environment, it adds group-write permissions to the ``.ssh/`` and ``.ssh/authorized_keys``: ``` gitea-server # ls -lad /data/git/.ssh/authorized_keys /data/git/.ssh /data/git /data / drwxr-xr-x 1 root root 62 Mar 12 08:27 / drwxrwsr-x 5 git bin 4096 Aug 25 2017 /data drwxr-xr-x 4 git git 4096 Mar 12 08:27 /data/git drwxrwS--- 2 git git 4096 Jan 22 22:38 /data/git/.ssh -rw-rw---- 1 git git 2370 Mar 1 07:58 /data/git/.ssh/authorized_keys ``` > My persistent volume is mounted over ``/data``. The symptoms are the following: ``` client $ ssh -p10022 -T git@mygitea.com Permission denied (publickey). ``` In the gitea logs: ``` Mar 12 08:18:50 sshd[31]: Authentication refused: bad ownership or modes for file /data/git/.ssh/authorized_keys Mar 12 08:18:50 sshd[31]: Connection closed by authenticating user git 10.37.64.0 port 36752 [preauth] ``` As a workaround I am removing write permissions from the group and removing others from rwx each time I recreate the Gitea container: ``` gitea-server # chmod g-w,o= /data/git/.ssh/authorized_keys /data/git/.ssh ``` ## Update I have just tested this with docker on my laptop and I was unable to reproduce the same: ``` docker run --rm -ti -p 10022:22 -p 3000:3000 -v /tmp/vol:/data gitea/gitea:1.3.3 ``` ``` gitea-v1.3.3 in a docker # ls -lad /data/git/.ssh/authorized_keys /data/git/.ssh /data/git /data drwxr-xr-x 1 root root 4096 Mar 12 08:50 / drwxr-xr-x 5 root root 4096 Mar 12 08:43 /data drwxr-xr-x 4 git git 4096 Mar 12 08:50 /data/git drwx------ 2 git git 4096 Mar 12 08:50 /data/git/.ssh -rw------- 1 git git 905 Mar 12 08:50 /data/git/.ssh/authorized_keys ``` There must be something wrong with my volume as I was trying to mount it to ``/data`` under a different image and the data got setgid and group rwx again. Which is pretty strange on its own. ## Update 2 Okay, my issue was solely due to the Kubernetes's ``fsGroup`` parameter that I was using (set either via ``securityContext`` or a PodSecurityPolicy ``MustRunAs``). It was making dirs/files permissions in volumes always get reset to 770/660 whenever POD is recreated with fsGroup used. One may either not use the ``fsGroup`` at all or as a workaround - change permissions right after the container is started, e.g. https://github.com/kubernetes/kubernetes/issues/2630#issuecomment-321009380
GiteaMirror commented 2025-11-02 03:47:43 -06:00
Author
Owner
Copy Link

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

Closing. Please re-open if needed.

@techknowlogick commented on GitHub (Sep 10, 2018): Closing. Please re-open if needed.
GiteaMirror commented 2025-11-02 03:47:44 -06:00
Author
Owner
Copy Link

@scofieldpeng commented on GitHub (Oct 7, 2018):

I have the same problem when I change my data to a new server. when I pull the repo via ssh, what i get are always the Connection closed by authenticating user git x.x.x.x port 61164 [preauth], i tried many ways to solve this like update /etc/ssh/sshd_config file, nothing worked.

Finally i think this is may be the wrong .ssh dir permission, i change it from 700 to 755 and it works! help this can help to someone:-)

Here is the result of /data/git/.ssh:

bash-4.4# ls -lah /data/git/.ssh
total 32
drwxr-xr-x    2 git      git         4.0K Oct  7 07:20 .
drwxr-xr-x    4 git      git         4.0K Oct  7 07:23 ..
-rw-------    1 git      git         1.6K Oct  7 07:20 authorized_keys
-rw-------    1 git      git          552 Oct  7 03:14 authorized_keys_1521647662.gitea_bak
-rw-------    1 git      git         1.1K Oct  7 03:14 authorized_keys_1524451963.gitea_bak
-rw-------    1 git      git         2.2K Oct  7 03:14 authorized_keys_1538881645.gitea_bak
-rw-------    1 git      git         1.6K Oct  7 03:14 authorized_keys_1538896812.gitea_bak
-rw-------    1 git      git           25 Oct  7 03:14 environment
@scofieldpeng commented on GitHub (Oct 7, 2018): I have the same problem when I change my data to a new server. when I pull the repo via ssh, what i get are always the `Connection closed by authenticating user git x.x.x.x port 61164 [preauth]`, i tried many ways to solve this like update `/etc/ssh/sshd_config` file, nothing worked. Finally i think this is may be the wrong `.ssh` dir permission, i change it from `700` to `755` and it works! help this can help to someone:-) Here is the result of `/data/git/.ssh`: ``` bash-4.4# ls -lah /data/git/.ssh total 32 drwxr-xr-x 2 git git 4.0K Oct 7 07:20 . drwxr-xr-x 4 git git 4.0K Oct 7 07:23 .. -rw------- 1 git git 1.6K Oct 7 07:20 authorized_keys -rw------- 1 git git 552 Oct 7 03:14 authorized_keys_1521647662.gitea_bak -rw------- 1 git git 1.1K Oct 7 03:14 authorized_keys_1524451963.gitea_bak -rw------- 1 git git 2.2K Oct 7 03:14 authorized_keys_1538881645.gitea_bak -rw------- 1 git git 1.6K Oct 7 03:14 authorized_keys_1538896812.gitea_bak -rw------- 1 git git 25 Oct 7 03:14 environment ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/question
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#1083
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?