elnappo / ansible-role-secure-openssh-server Goto Github PK

When setting:

  vars:
    - ssh_permit_root_login: no

The following error occurs:
failed: [XXX.XXX.XXX.XXX] => (item={u'regexp': u'^PermitRootLogin ', u'line': u'PermitRootLogin False'}) => {"failed": true, "item": {"line": "PermitRootLogin False", "regexp": "^PermitRootLogin "}, "msg": "failed to validate: rc:255 error:/tmp/tmpW9eey5 line 28: unsupported option \"False\".\r\n"}

It appears ansible's yaml syntax reads "no" as falsy and stores the value False. This can be worked around by using:

  vars:
    - ssh_permit_root_login: "no"

The simplest way forward might be to just document this in defaults/main.yml where the values for ssh_permit_root_login are already documented. I suspect the value "yes" (without quotes) will similarly be considered truthy and converted to True by ansible.

Actually, if we change the ssh_port variable, it ends up adding a line containing port <ssh_port value> to the sshd_config file. Thus, the daemon is listening on several ports, and the related ufw rules are added.

IMHO, the expected behaviour would be to have the daemon listening on a single port. It is actually a bit misleading: reading the config, we can expect ssh to be accessible on a single port, which might not be the case based on the "history" of the changes...

Main issue

Took me a while to understand that the validations where failing because sshd was not in my user's PATH.
Therefore, I think it might be useful to add a check to the pre.yml file to verify that.

For debian users

sshd being located in /usr/sbin, ansible user will need sudo capabilities.
Adding a become instruction solves the problem, example:

roles:
  - { role: elnappoo.secure-openssh-server,
      become: yes }