SSH Authentication Refused: bad ownership or modes for authorized_keys despite all permission flags being correct on inspection #12525

New Issue

GiteaMirror · 2025-11-02T10:12:48-06:00

GiteaMirror commented

2025-11-02 10:12:48 -06:00

Originally created by @CakePost on GitHub (Feb 24, 2024).

When attempting to run:

git clone [git@](mailto:git@git.inkoverflow.com)[redacted].com:[redacted]/[redacted].git

The following errors were thrown by my gitea instance. This indicates to me that my SSH request is not being captured by the host system and that the gitea instance SSH server is the one denying the request. I’ve verified that git is using the key I have registered with gitea.

Authentication refused: bad ownership or modes for file /data/git/.ssh/authorized_keys
Connection closed by authenticating user git [redacted IP] port 54694 [preauth]

To verify that it wasn’t a key issue, I also tried just SSHing into the server directly with

ssh -i ~/.ssh/id_rsa git@[redacted].com

Authentication refused: bad ownership or modes for file /data/git/.ssh/authorized_keys
Connection closed by authenticating user git [redacted IP] port 54842 [preauth]

I attached to the docker instance with a shell using the following command and investigated the ids set on the authorized_keys file and .ssh folder.

docker container exec -it 8f7 /bin/bash

I navigated to the directory in the docker instance and verified that the ownership of those files was being correctly mapped to the git user; the server should have no issue

Showing the group and user ids directly.

I checked that the authorized_keys file did indeed contain the ssh key for my user, as uploaded through the UI.

I triple checked that the key that I’m using is indeed the one that gitea has in the authorized_keys file.

The errors listed above seem to indicate that gitea is unhappy with the ownership flags on the authorized_key file despite the ownership files being precisely right. The one thing that might be tripping it up is that the group id is 998 instead of 1000, which makes me suspect that this might be a bug. It’s difficult for me to validate that, however.

Gitea Version

1.21.6

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

2.30.2

Operating System

Debian 10.2.1-6

How are you running Gitea?

This is the docker compose file used to launch the gitea instance. Note the use of USER_GID=998:

version: "3.9"
services:
  gitea:
    image: gitea/gitea:latest
    restart: always
    hostname: [REDACTED IP]
    environment:
      - USER=git
      - USER_UID=1000
      - USER_GID=998
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=giteadb:5432
      - GITEA__database__NAME=[REDACTED]
      - GITEA__database__USER=[REDACTED]
      - GITEA__database__PASSWD=[REDACTED]
    networks:
      - gitea
    ports:
      - 3000:3000
      - 22:22
    volumes:
      - /[REDACTED]/gitea/data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    shm_size: 256m
    depends_on:
      - giteadb

  giteadb:
    image: postgres:14
    restart: always
    environment:
      - POSTGRES_USER=[REDACTED]
      - POSTGRES_PASSWORD=[REDACTED]
      - POSTGRES_DB=[REDACTED]
    networks:
      - gitea
    volumes:
      - /[REDACTED]/gitea/db:/var/lib/postgresql/data

  runner:
    image: gitea/act_runner:latest
    restart: always
    depends_on:
      - gitea
    volumes:
      - /[REDACTED]/data/act_runner:/data
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - GITEA_INSTANCE_URL=https://[REDACTED].com
      - GITEA_RUNNER_REGISTRATION_TOKEN=[REDACTED]
networks:
  gitea:
    external: false

Database

PostgreSQL

Originally created by @CakePost on GitHub (Feb 24, 2024). When attempting to run: ```docker git clone [git@](mailto:git@git.inkoverflow.com)[redacted].com:[redacted]/[redacted].git ``` The following errors were thrown by my gitea instance. This indicates to me that my SSH request is not being captured by the host system and that the gitea instance SSH server is the one denying the request. I’ve verified that git is using the key I have registered with gitea. ```docker Authentication refused: bad ownership or modes for file /data/git/.ssh/authorized_keys Connection closed by authenticating user git [redacted IP] port 54694 [preauth] ``` To verify that it wasn’t a key issue, I also tried just SSHing into the server directly with ```docker ssh -i ~/.ssh/id_rsa git@[redacted].com ``` ```docker Authentication refused: bad ownership or modes for file /data/git/.ssh/authorized_keys Connection closed by authenticating user git [redacted IP] port 54842 [preauth] ``` I attached to the docker instance with a shell using the following command and investigated the ids set on the authorized_keys file and .ssh folder. ```docker docker container exec -it 8f7 /bin/bash ``` I navigated to the directory in the docker instance and verified that the ownership of those files was being correctly mapped to the git user; the server should have no issue ![Untitled](https://github.com/go-gitea/gitea/assets/94595995/dccf29c6-71d5-4b67-a7ee-1e08f55ebbc3) Showing the group and user ids directly. ![Untitled 1](https://github.com/go-gitea/gitea/assets/94595995/9d7b49bb-9000-4cb9-af0a-0573ef67627e) I checked that the authorized_keys file did indeed contain the ssh key for my user, as uploaded through the UI. I triple checked that the key that I’m using is indeed the one that gitea has in the authorized_keys file. ![Untitled 2](https://github.com/go-gitea/gitea/assets/94595995/4a78223a-1154-4b6c-8c80-f849fe334d20) The errors listed above seem to indicate that gitea is unhappy with the ownership flags on the `authorized_key` file despite the ownership files being precisely right. The one thing that might be tripping it up is that the group id is 998 instead of 1000, which makes me suspect that this might be a bug. It’s difficult for me to validate that, however. ### Gitea Version 1.21.6 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version 2.30.2 ### Operating System Debian 10.2.1-6 ### How are you running Gitea? This is the docker compose file used to launch the gitea instance. Note the use of `USER_GID=998`: ```docker version: "3.9" services: gitea: image: gitea/gitea:latest restart: always hostname: [REDACTED IP] environment: - USER=git - USER_UID=1000 - USER_GID=998 - GITEA__database__DB_TYPE=postgres - GITEA__database__HOST=giteadb:5432 - GITEA__database__NAME=[REDACTED] - GITEA__database__USER=[REDACTED] - GITEA__database__PASSWD=[REDACTED] networks: - gitea ports: - 3000:3000 - 22:22 volumes: - /[REDACTED]/gitea/data:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro shm_size: 256m depends_on: - giteadb giteadb: image: postgres:14 restart: always environment: - POSTGRES_USER=[REDACTED] - POSTGRES_PASSWORD=[REDACTED] - POSTGRES_DB=[REDACTED] networks: - gitea volumes: - /[REDACTED]/gitea/db:/var/lib/postgresql/data runner: image: gitea/act_runner:latest restart: always depends_on: - gitea volumes: - /[REDACTED]/data/act_runner:/data - /var/run/docker.sock:/var/run/docker.sock environment: - GITEA_INSTANCE_URL=https://[REDACTED].com - GITEA_RUNNER_REGISTRATION_TOKEN=[REDACTED] networks: gitea: external: false ``` ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 10:12:48 -06:00

GiteaMirror closed this issue

2025-11-02 10:12:48 -06:00

GiteaMirror commented

2025-11-02 10:12:48 -06:00

@CakePost commented on GitHub (Feb 24, 2024):

I wanted to verify which user was being used inside the docker instance to run gitea just to make sure it matched the filesystem file permissions, and indeed it does.

Interestingly, the sshd process is running under root- I wonder if that could be causing issues?

@CakePost commented on GitHub (Feb 24, 2024): I wanted to verify which user was being used inside the docker instance to run gitea just to make sure it matched the filesystem file permissions, and indeed it does. ![image](https://github.com/go-gitea/gitea/assets/94595995/e9ff7666-9435-47bf-ba4a-91678841517c) Interestingly, the sshd process is running under root- I wonder if that could be causing issues?

GiteaMirror commented

2025-11-02 10:12:49 -06:00

@CakePost commented on GitHub (Feb 24, 2024):

I worked out the problem with this, and that is that the drive that the docker volumes are located on was mounted such that all files on the drive were automatically getting set to rwrwrw permissions. Unfortunately, this drive is a share and thus does not enable fine grained permission bits for specific files or anything- all files are rwrwrw.

For other people that might also have this issue, my system was configured such that the drive mount point has all its configuration in /etc/fstab which is standard.

I changed file_mode from 666 to 600 and dir_mode from 777 to 700.

//[REDACTED]/backup /mnt cifs iocharset=utf8,rw,noacl,noperm,forceuid,forcegid,credentials=[REDACTED],uid=1000,gid=998,file_mode=0600,dir_mode=0700 0 0

Effectively, the authroized_keys file needs to have only user rw permissions (600) or else the system complains and will not allow the SSH connection to proceed.

@CakePost commented on GitHub (Feb 24, 2024): I worked out the problem with this, and that is that the drive that the docker volumes are located on was mounted such that all files on the drive were automatically getting set to rwrwrw permissions. Unfortunately, this drive is a share and thus does not enable fine grained permission bits for specific files or anything- all files are rwrwrw. For other people that might also have this issue, my system was configured such that the drive mount point has all its configuration in `/etc/fstab` which is standard. I changed `file_mode` from 666 to 600 and `dir_mode` from 777 to 700. ``` //[REDACTED]/backup /mnt cifs iocharset=utf8,rw,noacl,noperm,forceuid,forcegid,credentials=[REDACTED],uid=1000,gid=998,file_mode=0600,dir_mode=0700 0 0 ``` Effectively, the `authroized_keys` file needs to have only user rw permissions (600) or else the system complains and will not allow the SSH connection to proceed.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12525