gitea
gitea copied to clipboard
go-gitea
gitea update breaks SSH even though no config was ever touched
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
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
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
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
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
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
How long could the container work normally? And did you do any special operations?
around a week and nothing was done server wise. Prior to 1.17 I never had such issues with Gitea.
"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.
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
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.
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
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?
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 ........
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.
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 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.
