Hardening sshd_config

[macie]

Hi, firstly, thanks for your effort with maintenance of a great project. It's unbelievable how difficult is to find just a Git server for docker.

I want to start discussion in this issue about configuration secure by default. There is a popular way to gain access to the server with SSH - by brute force login (with tools such as: hydra). I'm aware of few mitigations (in sshd_config):

• disable root login: PermitRootLogin no
• use key only authentication: PasswordAuthentication no and PubkeyAuthentication yes.

I think that, they should be set by default, because not all users may be aware of the problem. But this is a breaking change.

There are more options which looks interesting (such as limiting time of automatic disconnect), but I'm not sure if they are well suited for most people.

[rockstorm101]

Hi, firstly, thanks for your effort with maintenance of a great project.

Hi @macie, thank you for your kind words.

I want to start discussion in this issue about configuration secure by default. There is a popular way to gain access to the server with SSH - by brute force login (with tools such as: hydra). I'm aware of few mitigations (in sshd_config):

• disable root login: PermitRootLogin no

• use key only authentication: PasswordAuthentication no and PubkeyAuthentication yes.

I think that, they should be set by default, because not all users may be aware of the problem. But this is a breaking change.

I agree that this Docker image is not the most secure by default. Which brings up and interesting debate.

Note that the current Dockerfile does not manipulate the SSH server configuration file. Which means it uses the configuration provided by default when installing openssh. In my mind this makes sense. Users get the same user experience they would get if they installed openssh directly on their systems instead of through Docker. At least, this is the behavior I would expect from a Docker image so I don't get any surprises when using the image vs. using the system installation (which I might be already familiar with).

Of course, the above would not be an issue for a user that's not familiar with the SSH server configuration and therefore won't be surprised if we customize it. Though it might be surprised in the future when other images or the system package do not behave the same.

So, IMHO, if those defaults you propose are better/safer/more recommended (which I agree) they should be the default/standard provided by the openssh package so everyone gets the same default behavior everywhere.

Let me know what you think.

[macie]

Good point. From the maintainer perspective, it's better to use defaults, which limits the scope of the future work.

But multiple times I saw people who use the docker as a magic black box. And they are not aware of the commonness of brute-forcing SSH. At least I wasn't, until I (fortunately) saw unsuccessful logins in the logs.

As a middle ground, I propose a new file in the example directory, called sshd_config-hardened (or ...-recommended) with mitigations mentioned earlier. It will give the users a hint, that default may be not the best for them. (I agree, that changing the defaults at the source will be better, but it will probably take some time, and at this moment I don't want to manage this).

To help you with maintaining this additional config, I've tried to set up automatic tests to run locally build image (at e2e branch). Unfortunately, I stuck with connecting to SSH server inside a build server (see: test_default_config.sh).