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).

[lindenaar]

Dear @macie and @rockstorm101,

The shipped OpenSSH version and config allows to override any configuration option by adding configuration files in /etc/ssh/sshd_config.d. settings provided here will be processed first and override the defaults in the main configuration file.

In my setup, I have used this by adding a volume mount and placing there config files to make changes like the ones mentioned above as well as disabling the SFTP access (so this could also be a solution for #18 ).

I guess this is in line with the approach chosen to not override too much of the defaults from the upstream package / distribution and I do agree that makes sense as all of these changes are implementation choices. Perhaps something to consider as the approach for all changes (including disabling password based logins) ?

[rockstorm101]

by adding configuration files in /etc/ssh/sshd_config.d. settings provided here will be processed first and override the defaults in the main configuration file.

I wasn't aware that the first value definition is predominant and any others are ignored. Thanks a lot for point this out.. I like it. I will implement this.

I'm thinking of gathering all hardening suggestions in a single file and add it to the examples folder. That might make things easy for novice users.

Thanks again.