Your Red Hat account gives you access to your member profile and preferences, and the following services based on your customer status:
Not registered yet? Here are a few reasons why you should be:
- Browse Knowledgebase articles, manage support cases and subscriptions, download updates, and more from one place.
- View users in your organization, and edit their account information, preferences, and permissions.
- Manage your Red Hat certifications, view exam history, and download certification-related logos and documents.
Your Red Hat account gives you access to your member profile, preferences, and other services depending on your customer status.
For your security, if you're on a public computer and have finished using your Red Hat services, please be sure to log out.Log out
There are two primary methods available to remotely manage and administer a Red Hat Enterprise Linux (RHEL) system: the command line interface over an SSH connection and the RHEL web console.
The web console provides a web-based graphical interface for managing and monitoring systems that can be used to complete a wide variety of tasks, such as managing storage, users and the firewall, monitoring performance metrics, reviewing log files, installing system updates and more. For more information about the web console, see the Managing systems using the RHEL 9 web console documentation.
If you are using the web console in your environment, it is important that you properly configure it to meet your organization's security requirements.
The RHEL web console is based on the upstream Cockpit project. Within RHEL, the RPM packages and other components use the Cockpit name, so you will see the names web console and Cockpit used interchangeably.
How to access the Red Hat web console
There are two main methods to access the web console:
Web console access methods that utilize an SSH connection.
Running the Cockpit web server on each RHEL host, and connecting over an HTTPS connection (which defaults to port 9090).
There are disadvantages of running the Cockpit web server on every host. One concern is that every open port on a system increases the attack surface. Also, the web console uses self-signed certificates by default, which can lead to man-in-the-middle attacks. Of course the web console also supports using signed TLS certificates, but this increases the time and effort needed to implement and maintain the web console. Based on these considerations, access methods that utilize an SSH connection are preferred.
This article focuses on the access methods that utilize an SSH connection. A future article will focus on running the Cockpit web server on each RHEL host.
Connecting to the web console using SSH
There are several ways to access the web console over an SSH connection:
Running the Cockpit web server on a single bastion host, and using it to connect over SSH to remote RHEL hosts.
Red Hat Satellite integration with the web console that utilizes Satellite remote execution SSH keys/infrastructure.
The Cockpit Client Flatpak application that can be run on Linux workstations, which uses SSH connections to connect to the web console on remote hosts (note that Red Hat does not provide support for the Cockpit Client Flatpak).
With these methods, the remote hosts on which you are accessing the web console do not need to be running the Cockpit web server, do not need any open ports in firewalls other than the SSH port, and TLS certificates do not need to be configured.
Another advantage of using SSH connections is that most environments already have SSH running and configured, and most organizations already have firewall / network communications configured to allow SSH traffic.
Due to these advantages, it is recommended to use one of the methods that connects to the web console over SSH rather than running the Cockpit web server on each host.
Using a bastion host
With the bastion host method, you start by installing and enabling the Cockpit web server on a single bastion host. In this example, my bastion host is running RHEL 9.
On my bastion host, I’ll start by running a command to install the cockpit package (on most RHEL installations this will be installed by default):
# dnf install cockpit
I’ll enable the Cockpit web server to listen on the bastion host by starting and enabling the cockpit.socket systemd unit.
# systemctl enable --now cockpit.socket
You’ll also want to verify the cockpit service is enabled in your firewall configuration.
Keep in mind that with this method, the single bastion host is running the Cockpit web server, and it should be properly configured and secured, should use a signed TLS certificate, etc. We'll cover this in more detail in our next article, which will focus on running the Cockpit web server.
After these steps have been completed, I can connect to my bastion host on port 9090 with a web browser and authenticate with a user account and password.
Once logged in, I can see my user name and host name in the upper right corner of the page. There is also a down arrow that opens a menu with an Add new host button.
On the Add new host screen, I can specify the host name for the remote host that I would like to access (in this example, the rhel9.example.com host). In my example, I’m using the same user name (brian) on both the bastion host and remote host so I can leave the user name field blank. In addition, I can specify a color that I would like to assign to this host (which will be shown at the top of the window later when I connect to the host), and then click the Add button.
If this is the first time I’ve established an SSH connection to this host, I’ll get a message that specifies I need to confirm the SSH key fingerprint for the remote host. Once confirmed, I’ll click the Accept key and connect button.
If I don’t already have SSH key authentication configured, I’ll be prompted to enter the password for the user on the remote host. I can optionally check the Authorize SSH key box, which will configure SSH key authentication to this remote host so that I will be able login to it without specifying the password in the future. I’ll then click the Log in button.
At this point, the connection has been configured and I now have two hosts listed in the menu on the left: my bastion host, and the rhel9.example.com remote host that I just configured. I can access the web console on rhel9.example.com by clicking on it in the menu. Because I specified that the web console should configure the SSH key, I am automatically logged in to the rhel9.example.com host when it is clicked.
When connected to the rhel9.example.com host, note that the yellow color I had chosen is shown at the top of the window:
Note that the remote hosts, such as rhel9.example.com, do not need to have the cockpit.socket enabled/running, do not need to have TLS certificates configured, and do not need to have any additional ports open in their firewall other than the SSH port.
Each remote host that you are connecting to needs to have the cockpit-system package installed. If you attempt to connect to a system without this package, you’ll receive a message that Cockpit is not installed.
If you are using a Linux workstation, you can make your local workstation your web console bastion host. With this configuration, you can opt to not open the cockpit service in the firewall so that the Cockpit web server is not accessible from remote hosts.
Red Hat Satellite integration with the web console
If you utilize Red Hat Satellite in your environment, you can optionally enable an integration between Satellite and the web console on your Satellite managed hosts.
This integration utilizes the remote execution framework and SSH keys that many Satellite customers already have configured in their environment.
As with other web console access methods that connect over SSH, on the remote hosts you do not need to have the cockpit-ws (Cockpit web server) package installed, you don’t need to have the cockpit.socket enabled/running, and you don’t need to have any firewall ports opened other than for SSH. You do need to have the cockpit-system package installed on the remote hosts.
For more information on how to configure the Satellite web console integration, see How to access and manage RHEL within Red Hat Satellite.
Cockpit Client Flatpak
If you are using a Linux workstation, the Cockpit Client Flatpak is another way to access the web console on remote servers utilizing an SSH connection.
Note that Red Hat does not provide support for the Cockpit Client Flatpak.
Once the Cockpit Client Flatpak is installed and started, you’ll be presented with a screen prompting you to specify a host name. In this example, I’ll specify that I would like to connect to the rhel9.example.com host using the brian user account.
If this is the first time you’ve connected, you’ll be prompted to verify and accept the host SSH key. If you have configured SSH key authentication, you’ll be automatically logged in to the web console on the host. If you don’t have SSH key authentication, you’ll be prompted to type the password for the user you are connecting as.
As with other web console access methods that connect over SSH, on the remote hosts you do not need to have the cockpit-ws (Cockpit web server) package installed, you don’t need to have the cockpit.socket enabled/running, and you don’t need to have any additional firewall ports opened other than for SSH. You do need to have the cockpit-system package installed on the remote hosts.
The web console is a great way to effectively manage your RHEL environment, however you need to implement the web console in a way that meets your security requirements and needs. In this article we covered SSH access methods for the web console. In a future article we'll cover accessing the web console with the Cockpit web server.
If you are new to the RHEL web console and want to try it out and learn more, head over to Red Hat Enterprise Linux Self-Paced Labs where we have a number of hands-on labs available, including labs related to the web console.
About the author
Brian Smith is a Product Manager at Red Hat focused on RHEL automation and management. He has been at Red Hat since 2018, previously working with Public Sector customers as a Technical Account Manager (TAM).