I performed a new install on a new cloud provider, and although “PasswordAuthenticaiton no” was present in the sshd_config file, and the Mail-in-a-box status checked was not flagging SSH being open for password logins, I could still log in via password.
Within the sshd_config file was:
Include /etc/ssh/sshd_config.d/*.conf
Within this directory was a file: 50-cloud-init.conf
which contained a single entry “PasswordAuthenticaiton yes”
I propose an improvement to have the Status checks also parse the config file for any “Include” entries, and either (1) parse those additional files for the PW = yes entry, so it won’t have this false negative that SSH is secure (no password logins) or (2) just simply state SSH check is inconclusive and to manually check any of these Include config files.
Well spotted I’ve just checked and I had the same thing, a sshd_config.d/50-cloud-init.conf file that includes PasswordAuthentication yes. Dangerous, as sshd config is first-come-first serve … later config specs do not override earlier ones! Easy enough to fix, if you’re looking for it.
My MIAB box was rebuilt from scratch only a couple of weeks ago. Not sure how that file got there. I’ve got 2 other ubuntu server boxes (not MIAB, not x64) and that file does not exist. Anyone else got that file?
That file doesn’t seem to come from MIAB setup. It could have been dragged in by an Ubuntu update at some stage. I wonder what package did it? It’s an obvious way to make servers more vulnerable to scans.
I have proposed something similar. It changes the way Mailinabox parses sshd configuration. Not by parsing the on-disk configuration files, but by parsing the configuration as interpreted by sshd itself (using the ssh -T command). This way, any files included in e.g. sshd_config.d are parsed as well.
It’s a pull request, so a patch. I have it running on my own system.
It was inspired by someone (I think on slack) who encountered the same thing as the topic starter.
Thank you @KiekerJan. This is a much better solution (using sshd -T)
From the sshd command manual, this would show the “effective configuration”, instead of multiple conflicting entires.
As I understand it, entries at the bottom of the sshd_config files take priority over entries above (so if you have password authentication no, then below that have password authentication yes, the yes would win, and then priority from the other config files, no mater what you had in sshd_config base file. Which can cause a lot of confusion, but using the command you suggested would alleviate all of that with the effective settings (net).
man sshd:
-T Extended test mode. Check the validity of the configuration file, output the effectiveconfiguration to stdout and then exit. Optionally, Match rules may be applied by specifying the connection parameters using one or more -C options.
Re the config files: sshd is a bit unusual in that the first config entry it sees is what it uses! So local config brought in by the #include at the top of the main file takes precedence over later entries.