Closed phantomski77 closed 8 months ago
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
I suspect this is an issue specific to Synology because its ACLs use an underlying POSIX permissions of 0777 and the container isn't aware of the host ACLs so all it will see is the 0777 permissions mask.
Just FYI, this is also happening on QNAP (QuTS Hero) when run in its Container Station (which is just a wrapper for Docker.)
Modifying the permissions in the config
volume does not work. Executing within the container itself I can see:
These files seem to be generated/contained within the Docker container env itself? Not sure how QNAP/Synology ACLs come into play...
/config
is a persistent mount that exists on the host filesystem, where the ACLs are in effect but invisible to the container; all it sees are the POSIX permissions which are not what it expects to see because ACLs. The files in /etc/ssh are just symlinks to the actual files in /config.
Ah, I see, didn't know about the symlinks (makes sense.) To address the problem, I did some changing of permissions via shell to make progress on this. I will try to share what I did and what I observed when I have the chance.
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
I would like to add here (also most probably for my own reference) that I ran into this same issue while running under WSL. It took a very long search and a lot of digging for me to find a solution out. My problem was that for WSL the permissions changes are not reflected on the windows file system when you chmod somthing. However you can enable this by setting the metadata option, which will allow you to manipulate the permissions with chmod that are remembered.
The steps that I took to fix this was:
sudo -i
vi /etc/wsl.conf
[automount]
options = "metadata"
wsl --terminate ubuntu
chmod 700 ./ssh_host_keys
chmod 600 ./ssh_host_keys/ssh_host*
to set the right permissions to start
with wsl, we recommend putting config folders on the local linux filesystem, not windows or remote mounts so they don't go through an abstraction layer that can and do break things
This issue is locked due to inactivity
Is there an existing issue for this?
Current Behavior
After creating a new openssh-server container, I couldn't connect to the SSH server with neither the key nor password. The ssh client responded with an error:
kex_exchange_identification: read: Connection reset by peer
Opening terminal for the container, I couldn't see sshd running and there was also no service listening on the port 2222. Checking the sshd log file, there were multiple errors for each individual host key file:
Finished by:
Indeed, by checking the permissions for host key files in
/etc/ssh
(or/config/ssh_host_keys
), they've been all set to 0777.By using
chmod 0600 ssh_host*
for changing the recommended permissions to 0600 (rw by owner) and restarting the container, everything worked as it should.I don't know if the host keys are generated with those permissions outright, or if it's the combination of my environment (Synology NAS) where I run the container and PUID/PGID of the user I'm setting it to (strictly limited access user), but this was the result for me on the clean run from the latest image (
sha256:098b5b04ceb2c43ced28a89ac27bfc073a5c806b96e07a64cbe744584994486e
)Expected Behavior
The container should start with the host keys permissions correctly set to 0600.
Steps To Reproduce
Environment
CPU architecture
x86-64
Docker creation
Container logs