No success using `RUN_USER=access`, `SSH_USER=access`

Install/Maintain/Configure
1

Hello all; I am running gitea @1.16.5 inside docker using a number of specialized names and paths.

I am hoping I can enable SSH as user access@base.silicon.am,
so in my config/conf/app.ini I placed:

RUN_USER              = access
APP_DATA_PATH         = /base
SSH_ROOT_PATH         = /base/access/.ssh

In my docker-compose.yml:

...
    environment:
      - USER=access
      - USER_UID=1001
      - USER_GID=1001
      ...
    volumes:
      - /var/home/core/memory/a/base:/base:z
      - /var/home/access/.ssh/:/base/access/.ssh:Z
      - ./config:/config/gitea:Z
      ...
    ports:
      - "450:443"
      - "90:80"
      - "127.0.0.1:2222:22"

Web port 90 is being picked up by Nginx Proxy Manager,
and mapped to the domain name base.assembled.app using SSL,
so I am no longer relying on gitea’s ACME certificate process.
/var/home/... is a quirk on Fedora CoreOS; has the same meaning as /home/...

In general, my approach is up and running. My only broken piece is SSH access, as in:

 
[grace@chesapeake domain]$ git push silicon main
access@base.silicon.am: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

 [grace@chesapeake domain]$ ssh access@silicon.am
access@silicon.am: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

The SSH keys I added through the web settings page
are appearing in /var/home/access/.ssh/authorized_keys,
including the prefixed command:

command="/usr/local/bin/gitea --config=/config/gitea/conf/app.ini serv key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-rsa AAAA....= grace@chesapeake

And the original Gitea Host Key is included also.

I had gone through three choices in the recommended SSH Container Passthrough guides:

  • SSHing Shim (with authorized_keys)
  • SSHing Shell (with authorized_keys)
  • SSH Shell with AuthorizedKeysCommand

The “Docker Shell” choices are likely more of a challenge,
because my access user is unable to run docker exec.

You can see the code I used during my approaches in my program code base.

Can anyone recommend more approaches or missing links?

1 Like