Connecting to the RHEL web console, part 2: Running the Cockpit web server

The Red Hat Enterprise Linux (RHEL) web console provides a web-based graphical interface for managing and monitoring systems. The web console can be used to complete a wide variety of tasks, such as managing storage, users, the firewall, monitoring performance metrics, reviewing log files, installing system updates and many others. See the Managing systems using the RHEL 9 web console documentation for more information.

Important note: Make sure that the web console is configured to meet your organization’s security requirements.

How to access the web console

There are two main methods to access the web console:

1. Web console access methods that utilize an SSH connection.

2. Running the Cockpit web server on each RHEL host, and connecting over an HTTPS connection (which defaults to port 9090).

Part 1 of this blog series focused on the web console access methods that utilize an SSH connection. This blog focuses on running the Cockpit web server on each RHEL host.

Overview of running the Cockpit web server on each RHEL host

Running the Cockpit web server on each host entails having the cockpit-ws (Cockpit web server) package installed, starting/enabling the cockpit.socket systemd unit with a command such as systemctl enable --now cockpit.socket, and opening the cockpit service in the firewall. The system will then listen for connections on a TCP port (port 9090 by default).

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 as well, however this adds to the amount of time and effort required to implement and maintain the web console in an environment.

Running the Cockpit web server on each RHEL host

As previously mentioned, running the Cockpit web server on each host is less preferred than using one of the options that utilize an SSH connection which was covered in part 1 of this blog series.

When utilizing the Cockpit web server on each host, you need to install the cockpit-ws package, start and enable the cockpit.socket systemd unit, and ensure the firewall is open for the cockpit service, as covered in the documentation.

By default, Cockpit will use a self-signed certificate, which is not recommended for a variety of security reasons. It is recommended that you configure a signed TLS certificate on each host. For more information on configuring the web console with a signed TLS certificate, see Using signed SSL certificates in Cockpit. You can also use a combination of the Cockpit and Certificate RHEL System Roles to automate the process of issuing signed certificates for use with the web console – for more information, see Automate RHEL web console deployments with the Cockpit and certificate RHEL system roles.

By default, the web console will allow any user to connect, including the root account. However, it is difficult to audit who did what on a system when multiple different people log in as the root account. The root username is also a known username that is often targeted by people trying to compromise systems. For these reasons, many organizations configure their SSH servers to not allow remote root logins. You can also configure the system to not allow root logins for the web console. For more information, see How to limit user access to the Cockpit service and GUI with PAM modules.

It is possible to configure the RHEL firewall to restrict access to the cockpit service to specific trusted IP addresses or networks rather than opening the cockpit service in the firewall for all remote hosts. For more information, see the Configuring firewalls and packet filters documentation.

If you have multiple network interfaces in your system (for example a management network interface and an application network interface), you can configure cockpit.socket to only listen on a specific interface (rather than listening on all interfaces). For more information, see How to make cockpit listen only on one interface.

On RHEL 8 and RHEL 9, the web console uses the GnuTLS settings configured by the system-wide crypto policy, so it is important to make sure your system-wide crypto policy is properly configured. For more information, see How to configure allowed ciphers and TLS versions in Cockpit.

There are a number of security-related items that can be configured in the cockpit.conf configuration file such as a login banner and an idle timeout that logs out inactive users (this only applies to users that logged in with a password). In addition, you might consider configuring the MaxStartups option to specify the maximum number of concurrent login attempts allowed. For more information, see the cockpit.conf manual page.

This screenshot shows an example of configuring a login banner to show an “Authorized users only!” message on the login screen.

This screenshot shows what happens when you have the idle timeout configured and are nearing the timeout period due to inactivity (note that this only applies to users that logged in with a password):

Using smart cards with the web console

It is also possible to authenticate to the web console with a smart card. For more information, see Configuring smart card authentication with the web console for centrally managed users.

When using smart cards, the system can also be configured to allow you to have password-less sudo with the smart card, or connect to remote hosts over SSH with the smart card. For more information, see Enabling password-less sudo for smart card users.

Learn more

The web console is a great way to manage your RHEL environment effectively However, make sure you implement the web console in a way that meets your security requirements and needs. 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.