Bug 2284275 - Unable to display ssh banner with sshd-baremetal-ansible.yaml
Summary: Unable to display ssh banner with sshd-baremetal-ansible.yaml
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: tripleo-ansible
Version: 17.1 (Wallaby)
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: z4
: 17.1
Assignee: OSP Team
QA Contact: Joe H. Rahme
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-06-02 15:24 UTC by tkuroda
Modified: 2025-03-22 04:25 UTC (History)
7 users (show)

Fixed In Version: tripleo-ansible-3.3.1-17.1.20240918100824.8debef3.el9ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-11-21 09:40:50 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-32184 0 None None None 2024-06-02 15:27:00 UTC
Red Hat Product Errata RHBA-2024:9974 0 None None None 2024-11-21 09:40:52 UTC

Description tkuroda 2024-06-02 15:24:10 UTC
This Bugzilla is related to Bug 2237000.


Description of problem:

CU can not display ssh banner with `OS::TripleO::Services::Sshd: /usr/share/openstack-tripleo-heat-templates/deployment/sshd/sshd-baremetal-ansible.yaml`


Version-Release number of selected component (if applicable):

* Red Hat OpenStack Platform release 17.1.3 (Wallaby)

* openstack-tripleo-heat-templates-14.3.1-17.1.20231103010840.el9ost.noarch


How reproducible:

Always


Steps to Reproduce:

1. Create following env file to display ssh banner

~~~
resource_registry:
  OS::TripleO::Services::Sshd: /usr/share/openstack-tripleo-heat-templates/deployment/sshd/sshd-baremetal-ansible.yaml

parameter_defaults:
  BannerText: |
    ******************************************************************
    *                        Test ssh banner                         *
    ******************************************************************
~~~

2. Add above env file to deploy script and deploy overcloud


Actual results:

ssh banner does not appear when ssh to overcloud nodes


Expected results:

ssh banner appears

/usr/share/openstack-tripleo-heat-templates/deployment/sshd/sshd-baremetal-ansible.yaml was updated to display ssh banner text by Bug 2237000.

So it is expected that ssh banner appears by specifying sshd-baremetal-ansible.yaml in the env file

Additional info:

This issue was reprodeced in my 17.1.3 fresh deployment.

Comment 1 Brendan Shephard 2024-06-03 03:34:20 UTC
So, I'm setting BannerText as per your reproducer example:

parameter_defaults:
  BannerText: |
    ******************************************************************
    *                        Test ssh banner                         *
    ******************************************************************

When I run the deployment I can see that it correctly sets tripleo_sshd_banner_enabled to true:

[root@director undercloud-ansible-hq92h_3v]# grep -A4 tripleo_sshd_ Undercloud/host_prep_tasks.yaml
    tripleo_sshd_banner_enabled: true
    tripleo_sshd_banner_text: '******************************************************************

      *                        Test ssh banner                         *

      ******************************************************************
--
    tripleo_sshd_message_of_the_day: ''
    tripleo_sshd_motd_enabled: false
    tripleo_sshd_password_authentication: 'yes'
    tripleo_sshd_server_options:
[...]

The banner_text is also set correctly. I'm also using 17.1.3:
# cat /etc/rhosp-release
Red Hat OpenStack Platform release 17.1.3 (Wallaby)


Looking at what tripleo-ansible does with this banner, we can see it copies the banner to /etc/issue:
https://github.com/openstack-archive/tripleo-ansible/blob/stable/wallaby/tripleo_ansible/roles/tripleo_sshd/tasks/main.yml#L84-L89

So, checking that location, I can see the banner has been correctly set:
# cat /etc/issue
******************************************************************
*                        Test ssh banner                         *
******************************************************************


Banner is seen when I login to the director VM:
director login: root
Password:

Last failed login: Sun Jun  2 21:55:24 EDT 2024 from 192.168.122.1 on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Sun Jun  2 21:55:10 on pts/1
[root@director ~]# exit
logout

******************************************************************
*                        Test ssh banner                         *
******************************************************************
Activate the web console with: systemctl enable --now cockpit.socket


So this part works fine, the next thing that should happen is the "Banner" parameter in /etc/ssh/sshd_config should be configured to point to /etc/issue. This happens during the Ansible execution here:
https://github.com/openstack-archive/tripleo-ansible/blob/stable/wallaby/tripleo_ansible/roles/tripleo_sshd/tasks/main.yml#L98-L108

Checking my environment, it doesn't seem to have been set:
[root@director undercloud-ansible-hq92h_3v]# grep -i banner /etc/ssh/sshd_config
[root@director undercloud-ansible-hq92h_3v]#

So it looks like the tripleo-heat-templates part works fine. But when tripleo-ansible tries to render that fact to set the "Banner" option, it seems to be failing. I'll dig into this.

Comment 4 Brendan Shephard 2024-06-03 05:30:55 UTC
So, I believe the issue is that we're re-using the Ansible variable for tripleo_sshd_server_options when we try to render the options here:



I have pushed a change to switch our set_fact implementation to use a private variable rather than re-using and clobbering the variable provided by tripleo-heat-templates:

❯ cat 0001-Use-private-variable-for-sshd_options.patch
From 4ed2e92fcd22a30ccba6be849ec79492e593d8e3 Mon Sep 17 00:00:00 2001
From: Brendan Shephard <bshephar>
Date: Mon, 3 Jun 2024 15:15:54 +1000
Subject: [PATCH] Use private variable for sshd_options

Use private variable when rendering sshd server options. This avoids
issues with clobbering user provided settings when we try to re-use
the same variable name.

Change-Id: Ia80ee5d1553caf8ae5a825f91a0fc9a22494de67
Signed-off-by: Brendan Shephard <bshephar>
---
 tripleo_ansible/roles/tripleo_sshd/tasks/main.yml               | 2 +-
 .../roles/tripleo_sshd/templates/sshd_config_block.j2           | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tripleo_ansible/roles/tripleo_sshd/tasks/main.yml b/tripleo_ansible/roles/tripleo_sshd/tasks/main.yml
index e9bc5925..95b478ed 100644
--- a/tripleo_ansible/roles/tripleo_sshd/tasks/main.yml
+++ b/tripleo_ansible/roles/tripleo_sshd/tasks/main.yml
@@ -97,7 +97,7 @@

     - name: Update sshd configuration options from vars
       set_fact:
-        tripleo_sshd_server_options: |-
+        _tripleo_sshd_server_options: |-
          {% set _ = tripleo_sshd_server_options.__setitem__('PasswordAuthentication', tripleo_sshd_password_authentication) %}
          {% if tripleo_sshd_banner_enabled %}
          {% set _ = tripleo_sshd_server_options.__setitem__('Banner', '/etc/issue') %}
diff --git a/tripleo_ansible/roles/tripleo_sshd/templates/sshd_config_block.j2 b/tripleo_ansible/roles/tripleo_sshd/templates/sshd_config_block.j2
index f80e3f4e..cd4c6838 100644
--- a/tripleo_ansible/roles/tripleo_sshd/templates/sshd_config_block.j2
+++ b/tripleo_ansible/roles/tripleo_sshd/templates/sshd_config_block.j2
@@ -1,6 +1,6 @@
 ## {{ ansible_managed }}

-{% for k, v in tripleo_sshd_server_options.items() %}
+{% for k, v in _tripleo_sshd_server_options.items() %}
 {%   if (v is iterable) and (v is not string) %}
 {%     set vars = (v | unique) %}
 {%     for var in vars %}
--
2.45.0

After making that change, I can see that it does indeed set the Banner option in my sshd_config:


[root@director undercloud-ansible-hq92h_3v]# cat /etc/ssh/sshd_config
## Ansible managed

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
Subsystem sftp  /usr/libexec/openssh/sftp-server
SyslogFacility AUTHPRIV
UseDNS no
UsePAM yes
X11Forwarding yes
PasswordAuthentication yes
Banner /etc/issue


And we can see that this does indeed work as the SSH Banner when I try to login.
[m3@localhost qe-jobs-testing]$ ssh stack.122.183
******************************************************************
*                        Test ssh banner                         *
******************************************************************
stack.122.183's password:

Comment 5 Brendan Shephard 2024-06-03 05:58:07 UTC
Sorry, I was missing the link. This is the part where we try to combine user provided data with the server_options:
https://github.com/openstack-archive/tripleo-ansible/blob/stable/wallaby/tripleo_ansible/roles/tripleo_sshd/tasks/main.yml#L98-L108

We can see that this variable is the same name as the one we provide from tripleo-heat-templates:
https://github.com/openstack-archive/tripleo-heat-templates/blob/stable/wallaby/deployment/sshd/sshd-baremetal-ansible.yaml#L88

So my proposed solution is to use an internal only variable when we set_fact to avoid clobbering the user-provided data from tripleo-heat-templates.

Comment 33 errata-xmlrpc 2024-11-21 09:40:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (RHOSP 17.1.4 bug fix and enhancement advisory), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2024:9974

Comment 34 Red Hat Bugzilla 2025-03-22 04:25:15 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days


Note You need to log in before you can comment on or make changes to this bug.