Gitea: Permission denied (publickey)

[axeloz]

• 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

[axeloz]

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 [email protected] <implicit> none [preauth]
Sep 20 10:26:10 new sshd[19104]: debug1: kex: server->client [email protected] <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]

Hello,

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

[lunny]

ssh -vvv [email protected] maybe you can debug the ssh

[realholgi]

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 (!).

[arno01]

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 [email protected]
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

[techknowlogick]

Closing. Please re-open if needed.

[scofieldpeng]

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