Este conteúdo não está disponível no idioma selecionado.
Chapter 14. Configuring secure communication by using the ssh and sshd RHEL System Roles
As an administrator, you can use the sshd System Role to configure SSH servers and the ssh System Role to configure SSH clients consistently on any number of RHEL systems at the same time by using Red Hat Ansible Automation Platform.
14.1. ssh Server System Role variables Copiar o linkLink copiado para a área de transferência!
In an sshd System Role playbook, you can define the parameters for the SSH configuration file according to your preferences and limitations.
If you do not configure these variables, the System Role produces an sshd_config file that matches the RHEL defaults.
In all cases, Booleans correctly render as yes and no in sshd configuration. You can define multi-line configuration items using lists. For example:
sshd_ListenAddress: - 0.0.0.0 - '::'
sshd_ListenAddress:
- 0.0.0.0
- '::'
renders as:
ListenAddress 0.0.0.0 ListenAddress ::
ListenAddress 0.0.0.0
ListenAddress ::
Variables for the sshd System Role
sshd_enable-
If set to
False, the role is completely disabled. Defaults toTrue. sshd_skip_defaults-
If set to
True, the System Role does not apply default values. Instead, you specify the complete set of configuration defaults by using either thesshddict, orsshd_Keyvariables. Defaults toFalse. sshd_manage_service-
If set to
False, the service is not managed, which means it is not enabled on boot and does not start or reload. Defaults toTrueexcept when running inside a container or AIX, because the Ansible service module does not currently supportenabledfor AIX. sshd_allow_reload-
If set to
False,sshddoes not reload after a change of configuration. This can help with troubleshooting. To apply the changed configuration, reloadsshdmanually. Defaults to the same value assshd_manage_serviceexcept on AIX, wheresshd_manage_servicedefaults toFalsebutsshd_allow_reloaddefaults toTrue. sshd_install_serviceIf set to
True, the role installs service files for thesshdservice. This overrides files provided in the operating system. Do not set toTrueunless you are configuring a second instance and you also change thesshd_servicevariable. Defaults toFalse.The role uses the files pointed by the following variables as templates:
sshd_service_template_service (default: templates/sshd.service.j2) sshd_service_template_at_service (default: templates/sshd@.service.j2) sshd_service_template_socket (default: templates/sshd.socket.j2)
sshd_service_template_service (default: templates/sshd.service.j2) sshd_service_template_at_service (default: templates/sshd@.service.j2) sshd_service_template_socket (default: templates/sshd.socket.j2)Copy to Clipboard Copied! Toggle word wrap Toggle overflow sshd_service-
This variable changes the
sshdservice name, which is useful for configuring a secondsshdservice instance. sshdA dict that contains configuration. For example:
sshd: Compression: yes ListenAddress: - 0.0.0.0sshd: Compression: yes ListenAddress: - 0.0.0.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow sshd_OptionNameYou can define options by using simple variables consisting of the
sshd_prefix and the option name instead of a dict. The simple variables override values in thesshddict.. For example:sshd_Compression: no
sshd_Compression: noCopy to Clipboard Copied! Toggle word wrap Toggle overflow sshd_matchandsshd_match_1tosshd_match_9-
A list of dicts or just a dict for a Match section. Note that these variables do not override match blocks as defined in the
sshddict. All of the sources will be reflected in the resulting configuration file.
Secondary variables for the sshd System Role
You can use these variables to override the defaults that correspond to each supported platform.
sshd_packages- You can override the default list of installed packages using this variable.
sshd_config_owner,sshd_config_group, andsshd_config_mode-
You can set the ownership and permissions for the
opensshconfiguration file that this role produces using these variables. sshd_config_file-
The path where this role saves the
opensshserver configuration produced. sshd_config_namespaceThe default value of this variable is null, which means that the role defines the entire content of the configuration file including system defaults. Alternatively, you can use this variable to invoke this role from other roles or from multiple places in a single playbook on systems that do not support drop-in directory. The
sshd_skip_defaultsvariable is ignored and no system defaults are used in this case.When this variable is set, the role places the configuration that you specify to configuration snippets in an existing configuration file under the given namespace. If your scenario requires applying the role several times, you need to select a different namespace for each application.
NoteLimitations of the
opensshconfiguration file still apply. For example, only the first option specified in a configuration file is effective for most of the configuration options.Technically, the role places snippets in "Match all" blocks, unless they contain other match blocks, to ensure they are applied regardless of the previous match blocks in the existing configuration file. This allows configuring any non-conflicting options from different roles invocations.
sshd_binary-
The path to the
sshdexecutable ofopenssh. sshd_service-
The name of the
sshdservice. By default, this variable contains the name of thesshdservice that the target platform uses. You can also use it to set the name of the customsshdservice when the role uses thesshd_install_servicevariable. sshd_verify_hostkeys-
Defaults to
auto. When set toauto, this lists all host keys that are present in the produced configuration file, and generates any paths that are not present. Additionally, permissions and file owners are set to default values. This is useful if the role is used in the deployment stage to make sure the service is able to start on the first attempt. To disable this check, set this variable to an empty list[]. sshd_hostkey_owner,sshd_hostkey_group,sshd_hostkey_mode-
Use these variables to set the ownership and permissions for the host keys from
sshd_verify_hostkeys. sshd_sysconfig-
On RHEL-based systems, this variable configures additional details of the
sshdservice. If set totrue, this role manages also the/etc/sysconfig/sshdconfiguration file based on the following configuration. Defaults tofalse. sshd_sysconfig_override_crypto_policy-
In RHEL, when set to
true, this variable overrides the system-wide crypto policy. Defaults tofalse. sshd_sysconfig_use_strong_rng-
On RHEL-based systems, this variable can force
sshdto reseed theopensslrandom number generator with the number of bytes given as the argument. The default is0, which disables this functionality. Do not turn this on if the system does not have a hardware random number generator.
14.2. Configuring OpenSSH servers using the sshd System Role Copiar o linkLink copiado para a área de transferência!
You can use the sshd System Role to configure multiple SSH servers by running an Ansible playbook.
You can use the sshd System Role with other System Roles that change SSH and SSHD configuration, for example the Identity Management RHEL System Roles. To prevent the configuration from being overwritten, make sure that the sshd role uses namespaces (RHEL 8 and earlier versions) or a drop-in directory (RHEL 9).
Prerequisites
-
Access and permissions to one or more managed nodes, which are systems you want to configure with the
sshdSystem Role. Access and permissions to a control node, which is a system from which Red Hat Ansible Core configures other systems.
On the control node:
-
The
ansible-coreandrhel-system-rolespackages are installed.
-
The
RHEL 8.0-8.5 provided access to a separate Ansible repository that contains Ansible Engine 2.9 for automation based on Ansible. Ansible Engine contains command-line utilities such as ansible, ansible-playbook, connectors such as docker and podman, and many plugins and modules. For information about how to obtain and install Ansible Engine, see the How to download and install Red Hat Ansible Engine Knowledgebase article.
RHEL 8.6 and 9.0 have introduced Ansible Core (provided as the ansible-core package), which contains the Ansible command-line utilities, commands, and a small set of built-in Ansible plugins. RHEL provides this package through the AppStream repository, and it has a limited scope of support. For more information, see the Scope of support for the Ansible Core package included in the RHEL 9 and RHEL 8.6 and later AppStream repositories Knowledgebase article.
- An inventory file which lists the managed nodes.
Procedure
Copy the example playbook for the
sshdSystem Role:cp /usr/share/doc/rhel-system-roles/sshd/example-root-login-playbook.yml path/custom-playbook.yml
# cp /usr/share/doc/rhel-system-roles/sshd/example-root-login-playbook.yml path/custom-playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open the copied playbook by using a text editor, for example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The playbook configures the managed node as an SSH server configured so that:
-
password and
rootuser login is disabled -
password and
rootuser login is enabled only from the subnet192.0.2.0/24
You can modify the variables according to your preferences. For more details, see SSH Server System Role variables.
-
password and
Optional: Verify playbook syntax.
ansible-playbook --syntax-check path/custom-playbook.yml
# ansible-playbook --syntax-check path/custom-playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run the playbook on your inventory file:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Log in to the SSH server:
ssh user1@10.1.1.1
$ ssh user1@10.1.1.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow Where:
-
user1is a user on the SSH server. -
10.1.1.1is the IP address of the SSH server.
-
Check the contents of the
sshd_configfile on the SSH server:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Check that you can connect to the server as root from the
192.0.2.0/24subnet:Determine your IP address:
hostname -I
$ hostname -I 192.0.2.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow If the IP address is within the
192.0.2.1-192.0.2.254range, you can connect to the server.Connect to the server as
root:ssh root@10.1.1.1
$ ssh root@10.1.1.1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.3. ssh System Role variables Copiar o linkLink copiado para a área de transferência!
In an ssh System Role playbook, you can define the parameters for the client SSH configuration file according to your preferences and limitations.
If you do not configure these variables, the System Role produces a global ssh_config file that matches the RHEL defaults.
In all cases, booleans correctly render as yes or no in ssh configuration. You can define multi-line configuration items using lists. For example:
LocalForward: - 22 localhost:2222 - 403 localhost:4003
LocalForward:
- 22 localhost:2222
- 403 localhost:4003
renders as:
LocalForward 22 localhost:2222 LocalForward 403 localhost:4003
LocalForward 22 localhost:2222
LocalForward 403 localhost:4003
The configuration options are case sensitive.
Variables for the ssh System Role
ssh_user-
You can define an existing user name for which the System Role modifies user-specific configuration. The user-specific configuration is saved in
~/.ssh/configof the given user. The default value is null, which modifies global configuration for all users. ssh_skip_defaults-
Defaults to
auto. If set toauto, the System Role writes the system-wide configuration file/etc/ssh/ssh_configand keeps the RHEL defaults defined there. Creating a drop-in configuration file, for example by defining thessh_drop_in_namevariable, automatically disables thessh_skip_defaultsvariable. ssh_drop_in_nameDefines the name for the drop-in configuration file, which is placed in the system-wide drop-in directory. The name is used in the template
/etc/ssh/ssh_config.d/{ssh_drop_in_name}.confto reference the configuration file to be modified. If the system does not support drop-in directory, the default value is null. If the system supports drop-in directories, the default value is00-ansible.WarningIf the system does not support drop-in directories, setting this option will make the play fail.
The suggested format is
NN-name, whereNNis a two-digit number used for ordering the configuration files andnameis any descriptive name for the content or the owner of the file.ssh- A dict that contains configuration options and their respective values.
ssh_OptionName-
You can define options by using simple variables consisting of the
ssh_prefix and the option name instead of a dict. The simple variables override values in thesshdict. ssh_additional_packages-
This role automatically installs the
opensshandopenssh-clientspackages, which are needed for the most common use cases. If you need to install additional packages, for example,openssh-keysignfor host-based authentication, you can specify them in this variable. ssh_config_fileThe path to which the role saves the configuration file produced. Default value:
-
If the system has a drop-in directory, the default value is defined by the template
/etc/ssh/ssh_config.d/{ssh_drop_in_name}.conf. -
If the system does not have a drop-in directory, the default value is
/etc/ssh/ssh_config. -
if the
ssh_uservariable is defined, the default value is~/.ssh/config.
-
If the system has a drop-in directory, the default value is defined by the template
ssh_config_owner,ssh_config_group,ssh_config_mode-
The owner, group and modes of the created configuration file. By default, the owner of the file is
root:root, and the mode is0644. Ifssh_useris defined, the mode is0600, and the owner and group are derived from the user name specified in thessh_uservariable.
14.4. Configuring OpenSSH clients using the ssh System Role Copiar o linkLink copiado para a área de transferência!
You can use the ssh System Role to configure multiple SSH clients by running an Ansible playbook.
You can use the ssh System Role with other System Roles that change SSH and SSHD configuration, for example the Identity Management RHEL System Roles. To prevent the configuration from being overwritten, make sure that the ssh role uses a drop-in directory (default from RHEL 8).
Prerequisites
-
Access and permissions to one or more managed nodes, which are systems you want to configure with the
sshSystem Role. Access and permissions to a control node, which is a system from which Red Hat Ansible Core configures other systems.
On the control node:
-
The
ansible-coreandrhel-system-rolespackages are installed.
-
The
RHEL 8.0-8.5 provided access to a separate Ansible repository that contains Ansible Engine 2.9 for automation based on Ansible. Ansible Engine contains command-line utilities such as ansible, ansible-playbook, connectors such as docker and podman, and many plugins and modules. For information about how to obtain and install Ansible Engine, see the How to download and install Red Hat Ansible Engine Knowledgebase article.
RHEL 8.6 and 9.0 have introduced Ansible Core (provided as the ansible-core package), which contains the Ansible command-line utilities, commands, and a small set of built-in Ansible plugins. RHEL provides this package through the AppStream repository, and it has a limited scope of support. For more information, see the Scope of support for the Ansible Core package included in the RHEL 9 and RHEL 8.6 and later AppStream repositories Knowledgebase article.
- An inventory file which lists the managed nodes.
Procedure
Create a new
playbook.ymlfile with the following content:Copy to Clipboard Copied! Toggle word wrap Toggle overflow This playbook configures the
rootuser’s SSH client preferences on the managed nodes with the following configurations:- Compression is enabled.
-
ControlMaster multiplexing is set to
auto. -
The
examplealias for connecting to theexample.comhost isuser1. -
The
examplehost alias is created, which represents a connection to theexample.comhost the withuser1user name. - X11 forwarding is disabled.
Optionally, you can modify these variables according to your preferences. For more details, see
sshSystem Role variables .Optional: Verify playbook syntax.
ansible-playbook --syntax-check path/custom-playbook.yml
# ansible-playbook --syntax-check path/custom-playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run the playbook on your inventory file:
ansible-playbook -i inventory_file path/custom-playbook.yml
# ansible-playbook -i inventory_file path/custom-playbook.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Verify that the managed node has the correct configuration by opening the SSH configuration file in a text editor, for example:
vi ~root/.ssh/config
# vi ~root/.ssh/configCopy to Clipboard Copied! Toggle word wrap Toggle overflow After application of the example playbook shown above, the configuration file should have the following content:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.5. Using the sshd System Role for non-exclusive configuration Copiar o linkLink copiado para a área de transferência!
Normally, applying the sshd System Role overwrites the entire configuration. This may be problematic if you have previously adjusted the configuration, for example with a different System Role or playbook. To apply the sshd System Role for only selected configuration options while keeping other options in place, you can use the non-exclusive configuration.
In RHEL 8 and earlier, you can apply the non-exclusive configuration with a configuration snippet.
Prerequisites
-
Access and permissions to one or more managed nodes, which are systems you want to configure with the
sshdSystem Role. Access and permissions to a control node, which is a system from which Red Hat Ansible Core configures other systems.
On the control node:
-
The
ansible-corepackage is installed. - An inventory file which lists the managed nodes.
- A playbook for a different RHEL System Role.
-
The
Procedure
Add a configuration snippet with the
sshd_config_namespacevariable to the playbook:Copy to Clipboard Copied! Toggle word wrap Toggle overflow When you apply the playbook to the inventory, the role adds the following snippet, if not already present, to the
/etc/ssh/sshd_configfile.BEGIN sshd system role managed block: namespace <my-application> END sshd system role managed block: namespace <my-application>
# BEGIN sshd system role managed block: namespace <my-application> Match all AcceptEnv LANG LS_COLORS EDITOR # END sshd system role managed block: namespace <my-application>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Verification
Optional: Verify playbook syntax.
ansible-playbook --syntax-check playbook.yml -i inventory_file
# ansible-playbook --syntax-check playbook.yml -i inventory_fileCopy to Clipboard Copied! Toggle word wrap Toggle overflow