gitea update breaks SSH even though no config was ever touched #9357

@Draic commented on GitHub (Aug 5, 2022):

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 commented on GitHub (Aug 5, 2022): 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

GiteaMirror commented

@Draic commented on GitHub (Aug 6, 2022):

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 commented on GitHub (Aug 6, 2022): 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

GiteaMirror commented

@Draic commented on GitHub (Aug 6, 2022):

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

@Draic commented on GitHub (Aug 6, 2022): 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`

GiteaMirror commented

@techknowlogick commented on GitHub (Aug 6, 2022):

What is the output of docker info?

@techknowlogick commented on GitHub (Aug 6, 2022): What is the output of `docker info`?

GiteaMirror commented

@Draic commented on GitHub (Aug 6, 2022):

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 commented on GitHub (Aug 6, 2022): ``` 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 ```

GiteaMirror commented

@Draic commented on GitHub (Aug 17, 2022):

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

@Draic commented on GitHub (Aug 17, 2022): 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

GiteaMirror commented

@lunny commented on GitHub (Aug 17, 2022):

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

@lunny commented on GitHub (Aug 17, 2022): > How long could the container work normally? And did you do any special operations?

GiteaMirror commented

@Draic commented on GitHub (Aug 17, 2022):

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

@Draic commented on GitHub (Aug 17, 2022): around a week and nothing was done server wise. Prior to 1.17 I never had such issues with Gitea.

GiteaMirror commented

@wxiaoguang commented on GitHub (Aug 18, 2022):

"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 https://github.com/go-gitea/gitea/issues/20570#issuecomment-1218917337

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.

@wxiaoguang commented on GitHub (Aug 18, 2022): "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 https://github.com/go-gitea/gitea/issues/20570#issuecomment-1218917337 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.

GiteaMirror commented

@Draic commented on GitHub (Aug 18, 2022):

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

@Draic commented on GitHub (Aug 18, 2022): 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

GiteaMirror commented

@wxiaoguang commented on GitHub (Aug 18, 2022):

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 b98a42afb6/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.

@wxiaoguang commented on GitHub (Aug 18, 2022): 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.

GiteaMirror commented

@Draic commented on GitHub (Aug 18, 2022):

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

@Draic commented on GitHub (Aug 18, 2022): 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

GiteaMirror commented

@wxiaoguang commented on GitHub (Aug 18, 2022):

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?

@wxiaoguang commented on GitHub (Aug 18, 2022): 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?

GiteaMirror commented

@Draic commented on GitHub (Aug 18, 2022):

yes. With screenshots :) see above

@Draic commented on GitHub (Aug 18, 2022): yes. With screenshots :) see above

GiteaMirror commented

@wxiaoguang commented on GitHub (Aug 18, 2022):

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 ........

@wxiaoguang commented on GitHub (Aug 18, 2022): 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 ........

GiteaMirror commented

@Draic commented on GitHub (Aug 18, 2022):

fixed it by switching to gitlab

@Draic commented on GitHub (Aug 18, 2022): fixed it by switching to gitlab

GiteaMirror commented

@wxiaoguang commented on GitHub (Aug 18, 2022):

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.

@wxiaoguang commented on GitHub (Aug 18, 2022): 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.

GiteaMirror commented