You need not just accept that the ssh daemon itself is safe, but that:

- Your key management is safe. - The process manager you now need to introduce to start sshd and the app running is safe. - That the ssh daemon is sufficiently protected against abuse. - That your configuration of it is safe.

If you don't need ssh in every container to do achieve what you need to achieve, why do you want to have to deal with each of those and waste the extra resources of having a bunch of extra sshd's and process monitors running?

(To the last point: Yesterday we suffered an attempt at brute-forcing ssh on a public facing server. We're used to people trying to brute force passwords. But as it happens, it is "easy" to make openssh consume all of your servers resources if you don't block access on the network level in the event of an apparent attack; so if any of those ssh servers are reachable in any way from the outside, you have just increased your attack surface even if your key management and everything else is perfect and they have no way of actually getting in)

If you are worried about the attack surface, then SSH - as Baseimage-docker configures it - isn't that much of an issue. By default, we do not expose the SSH port to the public Internet, nor do we install any keys. Unless otherwise configured by the user, you first have to login to the host machine, and then from there login to the container through SSH.

While it's great that you ship with secure defaults, to me, if you're going to restrict it to access from the host only, that just makes it more pointless to run sshd in the containers vs. the alternatives presented in the article.

Like I already said, there is an ongoing discussion about replacing SSH with nsenter now that nsenter is a viable alternative: https://github.com/phusion/baseimage-docker/issues/102

SSH was purely chosen because until recently there wasn't a better alternative. lxc-attach stopped working out of the box since Docker 0.9. See https://news.ycombinator.com/item?id=7951042

To this point, one of the RFC documents for SSH explicitly calls out the fact that the protocol is vulnerable to denial of service attacks and suggest only allowing access from the IP addresses of known users.

Source: http://tools.ietf.org/html/rfc4251#section-9.3.5

It's not just that the protocol is vulnerable. With e.g. openssh you can not just deny access to the ssh service, you can max out CPU on the entire machine if you hammer it enough.

I recommend you read the submission, then!