Don't enable fail2ban by default for ssh

[jbicha]

While testing, I was able to consistently lock myself out of the Ubuntu 16.04 cloud images I was testing locally today. My guess at what went wrong is that ansible did not correctly whitelist me. When certain ansible commands failed 3 times within 10 minutes, suddenly it's impossible for me to access my server for 2 hours.

There were some other reports of lock outs here.

What problem is fail2ban for ssh trying to solve?
By default, debops only allows public key authentication for ssh. This means that is basically impossible for a typical Bad Guy to break into ssh. But locking system admins out of the only way they can access their server looks to me like far more of a Denial of Service problem than whatever is targeting port 22.

[drybjed]

The debops.fail2ban role is not enabled by default in the official debops-playbooks, you need to specifically enable it by adding a host to the [debops_service_fail2ban] inventory group. But I see that you are coming over from DebOps for WordPress, and i guess that fail2ban is enabled there by default. In DebOps for WordPress, debops.fail2ban is a dependency of the wordpress role so this will make it hard to enable/disable conditionally. @carlalexander, perhaps you should reconsider moving this role out from the dependencies and using it through inventory directly.

As for blocking admin access in the firewall. It's a bit convoluted. The debops.core role is the one that gathers the IP address of the management host (actually it grabs the IP address of the incoming host, so it should work through routers/jumphosts). Then this information is passed to the debops.ferm, debops.tcpwrappers and debops.sshd roles which should automatically whitelist the incoming management connections. Check if you have any entries related to "Ansible Controller" in your firewall/TCP Wrappers configuration.

[carlalexander]

Yeah, I'm not sure why it's not whitelisted. The regular debops playbook is run before the WordPress one. It should set it up right?

[jbicha]

@carlalexander I think my biggest issue was solved with debops/ansible-sshd#53

I've not been using debops recently but I didn't seem to otherwise experience problems with fail2ban (well, I think I sometimes had to run this rule or a similar rule twice or something but that's a different issue)

[carlalexander]

Awesome!