Why would anyone run an ssh server in an app container? You’d ssh to the host and attach to the shell of the container if you needed shell access for some reason. I’ve only ever needed shell access to debug something or test a file mount.
In fact, minimal or “distroless” containers don’t even have a shell.
I honestly can’t think of any good reason to run an ssh server in a container.
That’d be an unusual setup. If you have users deploying containers on your host – that you trust enough to run whatever containers, but don’t want to give them ssh to the host – you’d usually have some kind of frontend such as Portioner, where you can have container exec and such.
Containerization is not virtualization. It’s very possible to break out of containers, especially if configured badly, or if there are any found exploits in the container engine or even the kernel. Containers are “good enough” for the majority of projects, but it has never been designed to be a truly hardened sandbox.
Basically, if you’re running an OpenSSH server inside a container, it’s likely that you’ve gotten the wrong ideas about securing your environment, and thus some old libraries in an old Debian image is the least of your worries.
I don’t understand this scenario. I can’t fathom why this would ever be the case. It sounds like either a very poor use of containers, or a very niche situation that I just don’t understand.
Sounds like a VPS. I doubt docker is sandboxed securely enough you’d want to use it for such an operation. VPS to my knowledge is done by virtual machine.
“The backdoor targeted SSH servers by hooking into OpenSSH’s cryptographic functions through the liblzma.so library.”
Not exactly academic in this case.
Who’s running OpenSSH servers in their old Debian containers anyways?
You’re getting down voted and I have no idea why.
Why would anyone run an ssh server in an app container? You’d ssh to the host and attach to the shell of the container if you needed shell access for some reason. I’ve only ever needed shell access to debug something or test a file mount.
In fact, minimal or “distroless” containers don’t even have a shell.
I honestly can’t think of any good reason to run an ssh server in a container.
What if you didn’t have permission to access the host, only the container?
That’d be an unusual setup. If you have users deploying containers on your host – that you trust enough to run whatever containers, but don’t want to give them ssh to the host – you’d usually have some kind of frontend such as Portioner, where you can have container exec and such.
Containerization is not virtualization. It’s very possible to break out of containers, especially if configured badly, or if there are any found exploits in the container engine or even the kernel. Containers are “good enough” for the majority of projects, but it has never been designed to be a truly hardened sandbox.
Basically, if you’re running an OpenSSH server inside a container, it’s likely that you’ve gotten the wrong ideas about securing your environment, and thus some old libraries in an old Debian image is the least of your worries.
I don’t understand this scenario. I can’t fathom why this would ever be the case. It sounds like either a very poor use of containers, or a very niche situation that I just don’t understand.
Sounds like a VPS. I doubt docker is sandboxed securely enough you’d want to use it for such an operation. VPS to my knowledge is done by virtual machine.
@chunkystyles @kungen
> I honestly can’t think of any good reason to run an ssh server in a container.
An isolated virtual machine for untrusted users?
That’s not the kind of container that’s being discussed. These are app containers that are built to just run one app.