Unable to ChrootDirectory

[cybergrunge]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Modifying sshd_config with a custom-cont-init.d script to set ChrootDirectory leads to an Connection to *************** closed by remote host. error when trying to SSH/SFTP.

openssh log reads:
server lacks privileges to chroot to ChrootDirectory

Expected Behavior

I should be able to change the default directory I land on when SSHing/SFTPing.

Steps To Reproduce

1. Bind a volume in the docker-compose.yml containing a shell script that sed the sshd_config file to set ChrootDirectory
   (sed -i 's|#ChrootDirectory none|ChrootDirectory [directory]|' /etc/ssh/sshd_config)
2. Launch the container
3. Try to SSH into the container

Environment

- OS: Debian 12
- How docker service was installed: official process

CPU architecture

x86-64

Docker creation

...
services:
  openssh-server:
    image: lscr.io/linuxserver/openssh-server:latest
    container_name: openssh-server
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - SUDO_ACCESS=false #optional
      - PASSWORD_ACCESS=true #optional
      - USER_PASSWORD=[password] #optional
      - USER_NAME=[user] #optional
    volumes:
      - ./configs/openssh/custom-cont-init.d:/custom-cont-init.d:ro
      - [named volume]:[directory]
    ports:
      - 2222:2222
    restart: always

Container logs

User name is set to [user]
sudo is enabled with password.
ssh-keygen: generating new host keys: RSA ECDSA ED25519
sshd is listening on port 2222
User/password ssh access is enabled.
[custom-init] Files found, executing
[custom-init] update_sshd_config.sh: executing...
··· Modification de sshd_config ···
[custom-init] update_sshd_config.sh: exited 0
[ls.io-init] done.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[aptalca]

Openssh server is running as an unprivileged user and cannot set a chroot directory. But sandboxing is done at the container level, not app (openssh-server) level.

[cybergrunge]

So there is no way to land in a bound volume on connect, rather than put this volume among config files (or cd .. to exit /config and go to the volume)?

[aptalca]

The purpose of chroot directory is to sandbox the user from other folders, which is not necessary here as I mentioned earlier that the sandboxing is done at the container level instead.

What you're trying to do is just a side effect of that feature. If all you want is to change directory upon connect, there are other ways you can do that, including setting your client to run scripts on connect.

[aptalca]

What if there might be files that i do not want ssh users to access

Then don't bind mount those paths in the container. The user only has access to the container, not the host.

[cybergrunge]

There’s no sandboxing inside the container, user has full read access to the filesystem, including openssh configuration.
It can be confusing for non linux savvy users, that’s what some of us are worried about.

[aptalca]

The container itself is sandboxed from the host.

The filesystem you're referring to is the container's own filesystem, which is a barebones alpine OS. There is nothing crucial or sensitive in there. The user doesn't have access to the host's filesystem. What problem would it cause that the user has unprivileged access to that alpine OS inside the container?

Yes, the user has access to the openssh config. What are they gonna do? Give someone else access to that ssh container? They don't need config access for that. They can just share their private key if they wanted to. Worst thing they can do is mess up the config and lock themselves out. No big deal, just recreate the container.

If you have a real world applicable and tangible concern, please articulate it fully and provide a detailed example of how it could lead to an actual issue instead of vague statements like they have access to the filesystem.

[cybergrunge]

The real world applicable and tangible usecase is clear: if one gives access to a non tech savvy user, and the said user finds themselves lost just because of an unfortunate misclicking, or mess up the config and lock themselves out so as I have to intervene, then the UX is just fucked up.
Chroot jailing has a precise function, if this function is not possible in this case, just say it. Don’t assume nobody needs it.
Thanks for the discussion.

[thespad]

It's entirely possible, it's just not the designed use-case of the container image so it would take quite a bit of work to change its behaviour. It also wouldn't be something we can provide support for.

[aptalca]

UX is just f***** up.

Please watch your language. This is a public space.

Chroot jailing has a precise function, if this function is not possible in this case, just say it. Don’t assume nobody needs it.

see #83 (comment)

It doesn't sound like this is the right image for you. Perhaps you'd be better served by a different solution.