Roots Discourse

Whitelist dev box with Fail2Ban

I’ve been blocked from a staging.server by fail2ban.

I have repeatedly–I think–unbanned my local IP address as returned by

|- Number of jail:	2
`- Jail list:	ssh, sshd
root@ubuntu-s-staging-example-nyc1-01:/home/admin# fail2ban-client set ssh unbanip
root@ubuntu-s-staging-example-nyc1-01:/home/admin# fail2ban-client set sshd unbanip

Then I am able to ssh in manually, but when I try to run a provisioning it gets blocked again:

TASK [python_interpreter : Get Ubuntu version] ***********************************************************************************************************
System info:
  Ansible 2.9.13; Darwin
  Trellis version (per changelog): "Remove default Vagrant SMB credentials"
Failed to connect to the host via ssh: ssh: connect to host 206xxx.189.xx
port 22: Connection refused
fatal: [206xxx.189.xx]: UNREACHABLE! => {"changed": false, "unreachable": true}

Not finding much in the Trellis docs yet.

Am guessing that something is, maybe going wrong here with the way trellis is connecting, but it–I believe– is working fine connection to the production server.

Does trellis add my local ip address to ip_whitelist when it initially deploys?

Why does fail2ban block the IP again? Are there detailed fail2ban logs, including the IP and the reason?
Maybe you are using a different IP when connecting via ansible python SSH (IPv6?)?

Well all I’m seeing in /var/logs/fail2ban.log is this:

2021-02-24 23:35:33,087 fail2ban.filter         [670]: INFO    [ssh] Found - 2021-02-24 23:35:33
2021-02-24 23:35:33,193 fail2ban.filter         [670]: INFO    [sshd] Found - 2021-02-24 23:35:33
2021-02-24 23:35:33,244 fail2ban.actions        [670]: NOTICE  [sshd] Ban
2021-02-24 23:35:33,247 fail2ban.actions        [670]: NOTICE  [ssh] Ban
2021-02-24 23:45:34,133 fail2ban.actions        [670]: NOTICE  [ssh] Unban
2021-02-24 23:45:34,133 fail2ban.actions        [670]: NOTICE  [sshd] Unban

Is there another place to look?

Also, I seem to have solved the problem by:

  1. Disabling fail2ban: sudo systemctl stop fail2ban
  2. Re-provision the fail2ban tag: trellis provision --tags fail2ban staging

I could still use some clarity on if the IP of the provisioning computer is automatically whitelisted with fail2ban.

Hm, why does your fail2ban actually ban that IP address?
Is ansible connecting in a way that could be interpreted as malicious, e.g. too many connection attempts in a too short time?

Great. There are a bunch of these:

ROOT LOGIN REFUSED FROM port 64071 [preauth]
Connection closed by authenticating user root port 64071 [preauth]
Connection closed by port 49286 [preauth]

Don’t know why there would have been a root login attempted, though.

This only happens when ansible was used?
So ansible apparently is (mis)configured to use the root user for the SSH logins.
It tries it too often and fail2ban considers this as mailicious and (re-(bans the IP address.

Seems likely, but I don’t think Trellis is configured to connect as root:

sshd_permit_root_login: false


# Documentation:
admin_user: admin

# Also define 'vault_users' (`group_vars/staging/vault.yml`, `group_vars/production/vault.yml`)
  - name: "{{ web_user }}"
      - "{{ web_group }}"
      - "{{ lookup('file', '~/.ssh/') }}"
      # -
  - name: "{{ admin_user }}"
      - sudo
      - "{{ lookup('file', '~/.ssh/') }}"
      # -

web_user: web
web_group: www-data
  - "/usr/sbin/service php7.4-fpm *"

Is there a config elsewhere I’m missing?

It could be the hosts/ directory in your Trellis folder. I use those files for provisioning fresh instances when they require their initial password/root login. That would be the place for forcing ansible to use a different user as Trellis usually would (admin).

What do you mean by that? Those files are the source for the IP addresses for the various envs, right? I always just set mine like:



Run the playbook with very high verbosity (-vvvv). What SSH command ansible actually uses for establishing a connection? Also check the ansible.cfg and ~/.ssh/config.

Sorry, starsis. This issue is actually resolved by deactivating fail2ban on the server and running the fail2ban tasks (as noted above).

I was trying to get some clarity on how Trellis handles it.

So I can still do that if it would be useful. I was wondering if you meant you were using the hosts files in a different way than the default and something I might want to be hip to.

Apparently ansible tries to connect with a different, invalid user over SSH, which results in fail2ban re-banning the workstation IP. Ansible can be configured to use a specific user or password instead what is specified in Trellis. There are several ways to override the ansible connection settings.

Hopefully next time it happens, I’ll have the patience to dig deeper.