tonydm
commented
1 year ago With further investigation, I think I found why the authentication is failing. According to the sshd stderr output, there is a permissions or ownership issue.
~/DockerServices/gitea main ................................................................. 1m 30s user@svr1-dc1 05:02:55 PM
> docker inspect gitea_server| grep log
"LogPath": "/var/lib/docker/containers/c78871ef4cf88d94c7392e7f3fe4ae0a5793174dfe80e5e3b277d8c691caaeac/c78871ef4cf88d94c7392e7f3fe4ae0a5793174dfe80e5e3b277d8c691caaeac-json.log",
~/DockerServices/gitea main ........................................................................ user@svr1-dc1 05:03:32 PM
> sudo tail -f /var/lib/docker/containers/c78871ef4cf88d94c7392e7f3fe4ae0a5793174dfe80e5e3b277d8c691caaeac/c78871ef4cf88d94c7392e7f3fe4ae0a5793174dfe80e5e3b277d8c691caaeac-json.log
[sudo] password for user:
{"log":"chown: /data/ssh/ssh_host_dsa_key: Invalid argument\n","stream":"stderr","time":"2022-11-18T16:56:14.814645558Z"}
{"log":"chown: /data/ssh/ssh_host_dsa_key.pub: Invalid argument\n","stream":"stderr","time":"2022-11-18T16:56:14.815418222Z"}
{"log":"chown: /data/ssh/ssh_host_ecdsa_key: Invalid argument\n","stream":"stderr","time":"2022-11-18T16:56:14.816133861Z"}
{"log":"chown: /data/ssh/ssh_host_ecdsa_key.pub: Invalid argument\n","stream":"stderr","time":"2022-11-18T16:56:14.816938926Z"}
{"log":"chown: /data/ssh/ssh_host_ed25519_key: Invalid argument\n","stream":"stderr","time":"2022-11-18T16:56:14.817904488Z"}
{"log":"chown: /data/ssh/ssh_host_ed25519_key.pub: Invalid argument\n","stream":"stderr","time":"2022-11-18T16:56:14.818830153Z"}
{"log":"chown: /data/ssh/ssh_host_rsa_key: Invalid argument\n","stream":"stderr","time":"2022-11-18T16:56:14.81961883Z"}
{"log":"chown: /data/ssh/ssh_host_rsa_key.pub: Invalid argument\n","stream":"stderr","time":"2022-11-18T16:56:14.820309201Z"}
{"log":"Server listening on :: port 22.\r\n","stream":"stdout","time":"2022-11-18T16:56:14.892206031Z"}
{"log":"Server listening on 0.0.0.0 port 22.\r\n","stream":"stdout","time":"2022-11-18T16:56:14.892254756Z"}
{"log":"Authentication refused: bad ownership or modes for file /data/git/.ssh/authorized_keys\r\n","stream":"stdout","time":"2022-11-18T17:03:48.85431296Z"}
{"log":"Authentication refused: bad ownership or modes for file /data/git/.ssh/authorized_keys\r\n","stream":"stdout","time":"2022-11-18T17:03:48.860547911Z"}
{"log":"Connection closed by authenticating user git 10.0.2.5 port 47316 [preauth]\r\n","stream":"stdout","time":"2022-11-18T17:03:48.868574737Z"}The permissions are correct for the root dir and files respectively (644 for .ssh/, 600 for authorized_keys) But ownership nobody is in question. I have no idea of how/where/when the ownership was set to nobody. But where I'm perplexed is that I haven't touched the NFS Share permissions since it was set up to host the data for the Gitea data
bash-5.1#
bash-5.1# ll /data/git/
total 46
drwxr-xr-x 5 nobody nobody 7 Nov 18 13:51 ./
drwxrwxrwx 6 nobody nobody 6 Jun 22 15:06 ../
-rw------- 1 nobody nobody 170 Nov 18 13:51 .bash_history
-rw-r--r-- 1 nobody nobody 190 Jun 22 15:07 .gitconfig
drwx------ 2 nobody nobody 8 Nov 18 16:44 .ssh/
drwxr-xr-x 2 nobody nobody 2 Jun 22 15:07 lfs/
drwxr-xr-x 3 nobody nobody 3 Jun 22 15:14 repositories/
bash-5.1#
bash-5.1#
bash-5.1# ll /data/git/.ssh/
total 67
drwx------ 2 nobody nobody 8 Nov 18 16:44 ./
drwxr-xr-x 5 nobody nobody 7 Nov 18 13:51 ../
-rw------- 1 nobody nobody 549 Nov 18 16:47 authorized_keys
-rw------- 1 nobody nobody 274 Jun 22 15:08 authorized_keys_1659480267.gitea_bak
-rw------- 1 nobody nobody 549 Nov 16 20:17 authorized_keys_1668630208.gitea_bak
-rw------- 1 nobody nobody 549 Nov 16 20:23 authorized_keys_1668782632.gitea_bak
-rw------- 1 nobody nobody 274 Nov 18 14:43 authorized_keys_1668789855.gitea_bak
-rw------- 1 nobody nobody 25 Jun 22 15:06 environment
bash-5.1#
bash-5.1# git user - /etc/passwd & /etc/group
bash-5.1#
bash-5.1# cat /etc/passwd | grep git
git:x:1001:1001:Linux User,,,:/data/git:/bin/bash
bash-5.1#
bash-5.1#
bash-5.1# cat /etc/group | grep git
git:x:1001:git
bash-5.1#
bash-5.1# attempting to change ownership fails. may be related to the data residing on TrueNAS NFS share?
bash-5.1# chown -R git:git /data/git/.ssh
chown: /data/git/.ssh/environment: Invalid argument
chown: /data/git/.ssh/authorized_keys_1659480267.gitea_bak: Invalid argument
chown: /data/git/.ssh/authorized_keys_1668630208.gitea_bak: Invalid argument
chown: /data/git/.ssh/authorized_keys: Invalid argument
chown: /data/git/.ssh/authorized_keys_1668789855.gitea_bak: Invalid argument
chown: /data/git/.ssh/authorized_keys_1668782632.gitea_bak: Invalid argument
chown: /data/git/.ssh: Invalid argument
chown: /data/git/.ssh: Invalid argument
bash-5.1#
bash-5.1# chown -R 1001:1001 /data/git/.ssh/
chown: /data/git/.ssh/environment: Invalid argument
chown: /data/git/.ssh/authorized_keys_1659480267.gitea_bak: Invalid argument
chown: /data/git/.ssh/authorized_keys_1668630208.gitea_bak: Invalid argument
chown: /data/git/.ssh/authorized_keys: Invalid argument
chown: /data/git/.ssh/authorized_keys_1668789855.gitea_bak: Invalid argument
chown: /data/git/.ssh/authorized_keys_1668782632.gitea_bak: Invalid argument
chown: /data/git/.ssh/: Invalid argument
chown: /data/git/.ssh/: Invalid argument
Nomsplease
99rgosse
gylove1994
Description
Without any changes to the host, docker image version, docker-compose.yml file or data directory (config files), I can no longer access my repos via ssh. I can, however, still access the repos via the webui. I've read through the numerous issues posted w/o finding a cause or resolution. I've seen a number of posts that appear to be stale/closed w/o a resolution.
I have "Verified" keys in the user profile via the Webui. I also have a YubiKey configured. I removed it to verify that wasn't the cause. I've verified that the container
/data/git/.ssh/authorized_keysfile contains the relevant public keys. I've verified that the/etc/ssh/sshd_configfile points to the /data/git/.ssh directory.I even installed tcpdump (apk add tcpdump) to confirm that my connection from the client was indeed reaching the correct server and that there was no firewall filter blocking traffic to the docker container.
After verifying that everything seemed configured properly, etc., I moved to the next step and issued a docker pull to pull down the latest (today 11/18/2022). Still no joy. I don't understand the cause and hesitate at a complete reinstall as I find no reason for the failure in the first place. I don't want to repeat this scenario.
Thank you very much
within the container
within the container
Gitea Version
v1.17.3
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
https://gist.github.com/tonydm/ea7f990515f7891f4c61507e8f0821c6
Screenshots
No response
Git Version
2.34.1
Operating System
Ubuntu 22.04.1 LTS
How are you running Gitea?
Cloned gitea repo and made relative docker-compose.yml file changes.
Database
MySQL