AllowTCPForwarding set to `no` although I have `ssh_allow_tcp_forwarding: yes`

[jeanmonet]

Describe the bug
AllowTCPForwarding set to no although I have ssh_allow_tcp_forwarding: yes in my playbook (see playbook extract below).

Actual behavior
/etc/ssh/sshd_config has AllowTCPForwarding no instead of AllowTCPForwarding yes.
The following is terminal output extract when running the playbook:

+# Disable forwarding tcp connections.
+# no real advantage without denied shell access
+AllowTcpForwarding no

Playbook

    - import_role:
        name: dev-sec.ssh-hardening
      vars:
        ssh_server_ports: ['123']
        ssh_allow_users: 'some_user'
        ssh_print_motd: true
        ssh_allow_tcp_forwarding: yes

OS / Environment

Playbook runs from:

• Ubuntu 20.04

Target machine is:

• Fresh image of Ubuntu server 20.04 LTS (Python 3 installed)

Ansible Version

ansible 2.9.9
  config file = /.../ansible/ansible.cfg
  configured module search path = ['/home/SOME_USER/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/SOME_USER/miniconda3/envs/py38_env/lib/python3.8/site-packages/ansible
  executable location = /home/SOME_USER/miniconda3/envs/py38_env/bin/ansible
  python version = 3.8.1 (default, Jan  8 2020, 22:29:32) [GCC 7.3.0]

Role Version

current version

==> Has anyone else had this problem?

===Update===
I'm suspecting this happened because Ansible took the no and turned it into a boolean, whereas when looking at the code (in particular following this commit), it checks if the value is in list ['yes', 'no', 'all', 'local'], thus checks for a string, not boolean.
Consequently, it seems that it is necessary to set 'yes' / 'no' as a string (with quotes) as such:

ssh_allow_tcp_forwarding: 'yes'
# instead of:
# ssh_allow_tcp_forwarding: yes

I haven't yet tested this assumption but it seems correct. In this case, it may be necessary to explicitly explain in the documentation, next to ssh_allow_tcp_forwarding, that the values yes, no, all or local have be fed as Python string, ie with quotes.

[rndmh3ro]

I'm suspecting this happened because Ansible took the no and turned it into a boolean, whereas when looking at the code (in particular following this commit), it checks if the value is in list ['yes', 'no', 'all', 'local'], thus checks for a string, not boolean.
Consequently, it seems that it is necessary to set 'yes' / 'no' as a string (with quotes) as such:

That's correct.

I haven't yet tested this assumption but it seems correct. In this case, it may be necessary to explicitly explain in the documentation, next to ssh_allow_tcp_forwarding, that the values yes, no, all or local have be fed as Python string, ie with quotes.

Sounds like a good idea, the readme was obviously not explicit enough. Do you want to create a PR for this?

[jeanmonet]

Sure, this would be a suggested wording. If it's fine for you I'll create a PR:

'no' to disable TCP Forwarding. Set to 'yes' to allow TCP Forwarding. If you are using OpenSSH >= 6.2 version, you can specify 'yes', 'no', 'all' or 'local'.

Note: values passed to this variable must be strings, thus values 'yes' and 'no' should be passed with quotes.

Update: PR #288

[rndmh3ro]

Sounds great, go ahead!

[rndmh3ro]

Fixed by #288