gitea update breaks SSH even though no config was ever touched

[Draic]

Description

since updating the container to 1.17 I can't connect to my repositories via SSH. I always end up with a Permission denied (publickey). fatal: Could not read from remote repository.

I read that 1.17 changed what ssh configs are read, but I never touched any of these. Even if I remove and add my SSH key in in the interface, the key is still getting rejected since the update. Sadly the database version change denies me from just running an older gitea version until this issue gets resolved

Gitea Version

1.17.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

unraid

How are you running Gitea?

docker: https://registry.hub.docker.com/r/gitea/gitea

Database

SQLite

[Draic]

the log states the following issue: Authentication refused: bad ownership or modes for directory /data/git/.ssh

But the ownership and read/write rights are correct... and haven't changed

[Draic]

the files are owned by the right person and no other have permissions. When I delete the whole .ssh folder and gitea creates it anew, the folder created is set to root/root which Gitea then can't write to and crashes with error 500 trying to write a key to the folder. Obviously 1.17 is bugged

[Draic]

if I now restart the server it will fix the folder and file permissions to how they should be and a new authorized_keys can be created when I add the key. This file and everything was again created fresh by gitea itself and when you try to connect via ssh it still errors out Authentication refused: bad ownership or modes for directory /data/git/.ssh

[techknowlogick]

What is the output of docker info?

[Draic]

docker info
Client:
 Context:    default
 Debug Mode: false

Server:
 Containers: 30
  Running: 25
  Paused: 0
  Stopped: 5
 Images: 32
 Server Version: 20.10.14
 Storage Driver: btrfs
  Build Version: Btrfs v4.20.1 
  Library Version: 102
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc version: v1.0.3-0-gf46b6ba2
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.15.46-Unraid
 Operating System: Slackware 15.0 x86_64
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.06GiB
 Name: Prospero
 ID: - (removed)
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Product License: Community Engine

[Draic]

I made a fresh install on 1.17, which worked for a while. But now it is having the exact same problem as before, with permission errors when it tries to read the SSH key despite its permissions being correct as we established while troubleshooting the issue on Discord. I think 1.17 is flawed

[lunny]

How long could the container work normally? And did you do any special operations?

[Draic]

around a week and nothing was done server wise. Prior to 1.17 I never had such issues with Gitea.

[wxiaoguang]

"which worked for a while": then it means that Gitea doesn't likely have a problem.

Maybe there are other programs changing the filesystem. See my comments in #20570 (comment)

You should figure out why the permission changes inside docker if it is the case. Maybe your Unraid does something to the filesystem? I could not guess.

[Draic]

then tell me why I only see this problem from 1.17 forward? I already checked permissions and they are not changed. The file permission error is despite the file being owned by the gitea user and having the right permissions. I explained this earlier. There is nothing for me to fix with the permissions, it is gitea not reading them proper

[wxiaoguang]

I think you are asking a wrong question. If you google "Authentication refused: bad ownership or modes for directory", you will see that the message comes from OpenSSH, not from Gitea. OpenSSH could be more strict with new versions, just a guess. Do you think OpenSSH's code is incorrect? If so, please suggest them to fix the bug. https://github.com/openssh/openssh-portable/search?q=bad+ownership+or+modes+for+directory and https://github.com/openssh/openssh-portable/blob/b98a42afb69d60891eb0488935990df6ee571c4d/misc.c#L2216

I can understand that you thought that "It worked before", but I couldn't guess what happened on your side, I can not provide more help.

[Draic]

I will gladly provide all information if asked. But telling people to check their permissions not excepting the fact that all permissions are correct is what gets annoying. I provided screenshots of all file and folder permissions I was asked for on the gitea discord and the reply was they are set correctly, but gitea is not accepting them. The reply there was "no idea why". And this is hardly the only service I use that packages openssh and still the only one I have this problem with

Keep deflecting blame while people are reporting problems since last version. I'll check out alternatives to gitea

[wxiaoguang]

I think I have explained very clearly. Please collect the information inside the container.

Have you ever told people what the /data/git/.ssh looks like inside the container?

[Draic]

yes. With screenshots :) see above

[wxiaoguang]

Where is it ...... I can not see or understand. Sorry, maybe I am not qualified to help, I am just an open source contributor in my free time ........

[Draic]

fixed it by switching to gitlab

[wxiaoguang]

Well, you only provided the docker info, which is somewhat useful but doesn't help about the problem.

I really have no idea where is your report about your /data/git/.ssh owner/mode and other information. So, feel free to have your choice. ps: I am also a gitlab user.

[Draic]

in the Gitea Discord

[jedi7]

I'm also interested into the pictures with filesystem rights and how they are mounted into docker. I'm just user, but I can check it against my configuration.

[Draic]

see Gitea Discord then. Bye

[mpeter50]

@Draic My 2 cents: its nice that you have sent some information in the discord group, but that is first of all unsearchable, and then you didn't either post links to your discord uploads to this issue, which is for tracking progress, so it would be (and actually is) pretty hard for maintainers to follow where did you upload what.