Timeline for Safe dockerfile for SSH server, server keys permission
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Aug 20, 2024 at 22:05 | history | bounty ended | CommunityBot | ||
| S Aug 20, 2024 at 22:05 | history | notice removed | CommunityBot | ||
| Aug 14, 2024 at 5:53 | comment | added | Philip Couling | I’m not convinced by some of your assertions here. You seem to be trying to avoid things which would be normal on bare metal (outside a container). For example, nothing about running as root inside a container is worse than running as root outside a container. Is your goal to create an SSH container as a service in its own right rather than for admin access? | |
| Aug 14, 2024 at 3:15 | history | edited | Pablo A | CC BY-SA 4.0 |
Improved formatting. Minor fixes.
|
| Aug 12, 2024 at 21:02 | answer | added | larsks | timeline score: 0 | |
| S Aug 12, 2024 at 19:33 | history | bounty started | Poperton | ||
| S Aug 12, 2024 at 19:33 | history | notice added | Poperton | Draw attention | |
| Aug 10, 2024 at 7:31 | comment | added | Sotto Voce | Is there no potential use case that your admin users would need to ssh into the server and stop dockerd to change its config? If this use case exists, stopping dockerd would stop sshd's container, disconnecting the admin user and not allowing any new ssh connections until dockerd+container were somehow restarted. | |
| Aug 10, 2024 at 5:11 | comment | added | muru |
"the users that are connecting to this container could try to read the keys somehow" ... are they also connecting as the user user?
|
|
| Aug 10, 2024 at 4:11 | history | edited | aaa |
edited tags
|
|
| Aug 10, 2024 at 3:37 | history | edited | aaa | CC BY-SA 4.0 |
added 434 characters in body
|
| S Aug 10, 2024 at 3:36 | review | First questions | |||
| Aug 24, 2024 at 3:39 | |||||
| S Aug 10, 2024 at 3:36 | history | asked | aaa | CC BY-SA 4.0 |