Home

Ansible SSH

NOTE: Read carefully this page before using the role as it contains vital information on its usage, limitations and the potential problems that it can cause if not used properly and with the required attention. Especially read this paragraph.

This is a fairly opinionated yet flexible role to securely deploy and configure an OpenSSH server on a server machine.
Features of this Ansible role include:

• Almost complete customization of the OpenSSH configuration file through an abstracted set of Ansible variables.
• Injection of custom configuration files to integrate changes not covered by the role.
• Optional support for mandatory TOTP based authentication through PAM and Google Authenticator.
• Optional configuration of the Linux security subsystems (PAM, SecureTTY, Faillock, Access.conf, ...)
• Secure generation of a new set of prime numbers for the Diffie-Hellman Key Exchange.
• Handling of SELinux throughout the role execution (when supported).
• Secure SELinux-backed storage of the authorized keys of each user.
• Support for all authentication methods supported by OpenSSH (GSSAPI, Kerberos, PKI, PAM, Passwords, ...)

Supported platforms

The role has been written with the intent of being as much distro-agnostic as possible, however it is currently only being tested on RHEL based distributions (in particular Rocky Linux). If you have found compatibility issues please report them through an issue on this repository.

Gotchas and Known Problems

This role, as written in the first line of its description, is fairly opinionated. This means that:

• The user's authorized keys will always be saved in /etc/ssh/authorized-keys and if SELinux is available.
  • As a consequence of this an administrator will have to create this file for new users.
  • As a consequence of this users will not be able to add their own keys. This is by design.
  • This role will make no attempt to move the content of existing key authorization files or add the currently used key to said file.
• A key revocation list will always be saved in /etc/ssh/revoked-keys and will always be respected by the server.
• If SELinux is available it will always be used to enhance the security of its configuration and of the keys.

During its execution this role will change the SSH server config, path of the key authorization files and potentially PAM configuration. All of these steps have the possibility to permanently lock the user out of SSH access to the box. USE THIS ROLE WITH CAUTION! Make repeated tests on staging environments to make sure that nothing breaks with you, and remember that this role comes with no responsibility!