Can't get ssh pub keys into linuxserver/openssh-server

[freekvh]

I am trying to run linuxserver/openssh-server on a synology nas to get some decent ssh capabilities.

I'm using this docker compose:

services:
  openssh-server:
    image: lscr.io/linuxserver/openssh-server:latest
    container_name: openssh-server
    hostname: openssh-server #optional
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - PUBLIC_KEY_DIR=./pubkeys
      - SUDO_ACCESS=false #optional
      - PASSWORD_ACCESS=false #optional
      - USER_NAME=xxx #optional
    ports:
      - 2223:2222
    restart: unless-stopped

./pubkeys contains pubkey files:

But I keep getting this error:

$ ssh xxx@starry -p 2223
Received disconnect from 100.122.65.58 port 2223:2: Too many authentication failures
Disconnected from 100.122.65.58 port 2223

It does however work when I use PUBLIC_KEY_URL with my GH keys, so I know it should in principle work.

Am I missing something? Are my pubkeys not stored correctly? I just used the files from my .ssh folder.

Or am I not point to the folder correctly? I've also tried "/volume1/qodon/docker/pubkeys", "/volume1/qodon/docker/pubkeys/" and "qodon/docker/pubkeys" and many other variations.

Thanx.

[drizuid]

try adding -vvv to your ssh command to see the details of the issue

[freekvh]

try adding -vvv to your ssh command to see the details of the issue

Thanx, I did that. I see it trying a lot of things, like this (I believe there to be too much sensitive info to paste the whole thing):

debug1: Offering public key: freek@nixos ED25519 SHA256:DQ0RUHWbTXiWxxxw8mBxQ7s agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51

[aptalca]

Public key dir needs to be the path inside the container and definitely has to be an absolute path

[freekvh]

Ah, that makes sense, it is an environment after all. So I also need a volume then which links the outside folder to the inside. Let me test. Documentation could be a bit clearer in this case, it looks like a handy tool to get keys inside the container from outside, but it's not directly, it's an in-container tool to gather keys.

[freekvh]

Ok, yes this works, thanx!!

services:
  openssh-server:
    image: lscr.io/linuxserver/openssh-server:latest
    container_name: openssh-server
    hostname: openssh-server #optional
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - PUBLIC_KEY_DIR=/pubkeys
      - SUDO_ACCESS=false #optional
      - PASSWORD_ACCESS=false #optional
      - USER_NAME=dcdc #optional
    ports:
      - 2223:2222
    volumes:
      - /volume1/qodon/docker/pubkeys:/pubkeys
    restart: unless-stopped

[freekvh]

Ok apologies, perhaps I forgot to rebuild the container, but this does not seem to work now. Same error. Any suggestions?

[freekvh]

Ah, I know what happened, in the end I added the :ro, removing that makes it work again. Is that expected?

[anntnzrb]

Two issues:

1. Relative path doesn't work - PUBLIC_KEY_DIR must be an absolute path inside the container
2. Missing volume mount - your host pubkeys directory isn't mounted

Fix your docker-compose.yml:

environment:
  - PUBLIC_KEY_DIR=/mnt/pubkeys  # Absolute path
volumes:
  - ./pubkeys:/mnt/pubkeys:ro    # Mount host directory

The container reads all files in PUBLIC_KEY_DIR at startup and appends them to /config/.ssh/authorized_keys. Without the mount, the directory doesn't exist inside the container.

[freekvh]

Thanx, I had just figured it out (see one post higher).

[mrtnd]

the following should also work:

volumes:
   - /path/to/config:/config
   - /path/to/authorized_keys:/config/.ssh/authorized_keys

[aptalca]

That is not something we support or recommend. We provide several environment vars to get keys into the container properly.

[mrtnd]

Thank for the reply. Care to elaborate why it is not recommended? It's just a file you maintain, like any other option currently supported. The only difference I can think of is you probably don't have to recreate the container for changes to take effect. Is that maybe the concern?