4 ms·

i don't see that wrong to setup the ssh service, if i accept ssh daemon is safe which i do.

by drydot 12y ago

diminoten 12y ago
I recommend you read the submission, then!
vidarh 12y ago
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)
- FooBarWidget 12y ago
  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.
  - vidarh 12y ago
    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.
    - FooBarWidget 12y ago
      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 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 https://news.ycombinator.com/item?id=7951042
- ewindisch 12y ago
  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 http://tools.ietf.org/html/rfc4251#section-9.3.5
  - vidarh 12y ago
    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 don't see that wrong to setup the ssh service, if i accept ssh daemon is safe which i do.

by drydot 12y ago

i don't see that wrong to setup the ssh service, if i accept ssh daemon is safe which i do.

diminoten 12y ago

I recommend you read the submission, then!

vidarh 12y ago

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)

FooBarWidget 12y ago
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.
- vidarh 12y ago
  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.
  - FooBarWidget 12y ago
    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 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 https://news.ycombinator.com/item?id=7951042
ewindisch 12y ago
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 http://tools.ietf.org/html/rfc4251#section-9.3.5
- vidarh 12y ago
  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.