MaxAuthTries - Citation(s) for baseline choice.

[monobaila]

I'm new to Ansible and have got a lot of value from your ansible-ssh-hardening project, thanks!

I did hit one snag with the MaxAuthTries setting of 2, compared to the default of 6. I actually managed to lock myself out of a host due to my ssh agent offering different keys before the correct one, causing a "Too many authentication failures for XXX" disconnection. After discovering the issue I wanted to understand from the baseline why this setting is chosen.

I read the description for this control baseline and am struggling to see if changing this setting offers any tangible benefits for the increased risk of inconvenience (based on the fact the baseline already requires password login disabled).

I wanted to offer a general observation here. The internet is full of varying quality guides for hardening SSH with very little reference to reputable STIG or other similar frameworks for secure configuration. I think the vision for this project is fantastic, it should streamline things for many people but I think it's important to track why baseline settings are chosen, citations for any particular attack vectors and noting some of the tradeoffs for the decision. Otherwise it feels like just an extension of "cargo cult" style blog posts where everyone is offering their chosen secure settings with little critical evaluation on why this setting was chosen.

Are you able to provide some background on this setting?

I'm happy to open a PR for the ansible-ssh-hardening to update the documentation/faq to flag this, unfortunately as Ansible uses SSH as the control channel it's particularly sensitive to these types of issues!

[chris-rock]

Thank you @monobaila for reaching out and being so honest. We are very happy that you find our resources useful.

What are the benchmarks your rely on?

In general, we only accept controls that are based on trusted sources. In most cases those are guided by STIG or CIS. Historically, we have some rules that originated from NSA guidelines and Deutsche Telekom.

I cannot see where the control originated from?

This is the case for the content that is part of the project since the early days. We started with ServerSpec and it had no capacity to annotate checks when we migrated to InSpec. With newer contributions, we required references to trusted sources. A good example is https://github.com/dev-sec/windows-baseline/blob/master/controls/account_policies.rb#L3-L21

We strive to have those annotations for all controls to provide high-confidence in our profiles and automation. Any PR to add this metadata is very welcome!

Why is MaxAuthTries set to 2

In your case, the CIS guideline says that Ensure SSH MaxAuthTries is set to 4 or less.

One of the key benefits of the DevSec project is its ability for customization. For most values, we set defaults that can be overridden. This is not the case for MaxAuthTries yet, so feel free to open a PR to submit this improvement.

[monobaila]

Thanks for the detailed response @chris-rock, I've opened a tentative PR (#138) with some improvements - thanks for pointing me to a good reference example.

I've not had much time to put this together so hopefully there are no typos, I'm hoping the automated tests for the PR will blow up if I've done anything stupid!

[monobaila]

Spoke too soon, it's already blown up :)

I'll take a look when I have some time.

[monobaila]

I've fixed up my PR and the build is now clean.