Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Satellite 6.7 currently supports connecting with the console of the Host from Satellite UI itself, via cockpit integration with the help of remote execution feature.
If the remote_execution_ssh_user is set to root or we are using a non-root user with password-less sudo configured, once we connect to the host console from Satellite it will by-default log in to the cockpit user as a privileged user.
But when the remote_execution_ssh_user is set to a non-root user requiring a password to perform sudo operations, the above scenario changes i.e. when we connect to the host console from Satellite it will fail to perform sudo at the backend and will log in to the cockpit UI as a normal user i.e. an "Unprivileged session"
Version-Release number of selected component (if applicable):
Satellite 6.7.0
How reproducible:
Always
Steps to Reproduce:
1. Register an RHEL 7\8 Client with RH Satellite 6.7.
2. Create a user named ansible on the client host and add it to the wheel group.
3. In satellite, make sure to configure the REX settings in this way.
SSH User: ansible
Effective User: root
Effective User Method: sudo
Sudo password: <password for ansible user to become root using sudo>
4. Share SSH-keys from Satellite to the "ansible@client host" so that Remote Jobs on the host can be executed.
5. Configure cockpit integration as per the following doc for both Satellite and the client host.
--> https://access.redhat.com/documentation/en-us/red_hat_satellite/6.7/html/managing_hosts/host_management_and_monitoring_using_red_hat_web_console
6. Go to Hosts --> All Hosts --> Click on the HOst --> Click on Web Console
7. Once in the cockpit UI of that host, Click on the "Subscriptions" tab.
Actual results:
In cockpit UI, we will be able to see the following message while accessing the "Subscriptions" tab
~~~
The current user isn't allowed to access system subscription status.
Access denied
~~~
Reason: Unprivileged session as Satellite is not designed to pass the sudo password to the cockpit-bridge while performing the authentication.
Expected results:
From Satellite when we take the "Web Console" of a host using a non-root user, we should be able to get the session authenticated as "Privilege User" and should be able to see all the options and manage them.
Additional info:
Verified on Satellite 6.13 snap 11 using steps from the problem description, ssh user with sudo privileges is now also privileged in the cockpit console (can access subscriptions, screenshot will follow)
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 (Important: Satellite 6.13 Release), 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/RHSA-2023:2097
Description of problem: Satellite 6.7 currently supports connecting with the console of the Host from Satellite UI itself, via cockpit integration with the help of remote execution feature. If the remote_execution_ssh_user is set to root or we are using a non-root user with password-less sudo configured, once we connect to the host console from Satellite it will by-default log in to the cockpit user as a privileged user. But when the remote_execution_ssh_user is set to a non-root user requiring a password to perform sudo operations, the above scenario changes i.e. when we connect to the host console from Satellite it will fail to perform sudo at the backend and will log in to the cockpit UI as a normal user i.e. an "Unprivileged session" Version-Release number of selected component (if applicable): Satellite 6.7.0 How reproducible: Always Steps to Reproduce: 1. Register an RHEL 7\8 Client with RH Satellite 6.7. 2. Create a user named ansible on the client host and add it to the wheel group. 3. In satellite, make sure to configure the REX settings in this way. SSH User: ansible Effective User: root Effective User Method: sudo Sudo password: <password for ansible user to become root using sudo> 4. Share SSH-keys from Satellite to the "ansible@client host" so that Remote Jobs on the host can be executed. 5. Configure cockpit integration as per the following doc for both Satellite and the client host. --> https://access.redhat.com/documentation/en-us/red_hat_satellite/6.7/html/managing_hosts/host_management_and_monitoring_using_red_hat_web_console 6. Go to Hosts --> All Hosts --> Click on the HOst --> Click on Web Console 7. Once in the cockpit UI of that host, Click on the "Subscriptions" tab. Actual results: In cockpit UI, we will be able to see the following message while accessing the "Subscriptions" tab ~~~ The current user isn't allowed to access system subscription status. Access denied ~~~ Reason: Unprivileged session as Satellite is not designed to pass the sudo password to the cockpit-bridge while performing the authentication. Expected results: From Satellite when we take the "Web Console" of a host using a non-root user, we should be able to get the session authenticated as "Privilege User" and should be able to see all the options and manage them. Additional info: