Fix Cockpit Web Console Not Connecting on SUSE Linux Enterprise Server

If the Cockpit Web Console will not connect to a SUSE Linux Enterprise Server (SLES) host, first try https://SERVER_IP:9090, then verify that cockpit.socket is listening and that the firewall permits the Cockpit service in the zone used by the server's network interface. On a standard installation, these checks resolve the most common causes: a wrong URL or port, an inactive socket, missing Cockpit packages, or a blocked inbound connection.

This guide applies to SLES systems that use systemd and have Cockpit available from their configured product repositories. SUSE's current SLES 16 Cockpit guide documents the pattern installation and socket activation commands below. Package availability and names can vary by SLES service pack, module, and support entitlement, so on an older SLES 15 host confirm that Cockpit is offered by its enabled SUSE repositories before treating an installation error as a service fault.

Start with the symptom

Use the error in the browser to narrow the cause. A timeout or “site can’t be reached” usually points to routing, firewall rules, or a listener that is not active. A refused connection often means nothing is accepting connections on the selected address and port. A Cockpit sign-in page means the web service is reachable; a later authentication error is a separate account or policy problem. A certificate warning means HTTPS negotiation reached the server, but the browser does not trust the certificate or its name.

For example, suppose an administrator cannot open a server whose address is 192.0.2.25. Test https://192.0.2.25:9090 from a machine that should be allowed to administer it. Cockpit normally uses HTTPS on port 9090. Typing only the IP address may open a different service, and using http:// can lead to a redirect or a browser warning rather than the expected login view.

1. Check the URL and reachability

Confirm the server's current address from the SLES console or a trusted inventory, and include the port explicitly:

https://192.0.2.25:9090

From the client, test whether TCP port 9090 is reachable. On a Linux administration workstation with netcat installed, run:

nc -vz 192.0.2.25 9090

A successful TCP connection proves only that the port is reachable; it does not prove login will work. A timeout suggests checking the server's active firewall zone, any upstream network firewall, routing, and VPN access. A refusal suggests checking the listener on the SLES host. If netcat is unavailable, test from a browser or use another approved TCP connectivity tool rather than installing an unapproved utility on a production host.

2. Confirm Cockpit is installed and its socket is active

Connect through SSH or a local console and inspect the socket. Cockpit normally uses systemd socket activation: systemd listens for an incoming connection on behalf of Cockpit and starts the web service on demand. Because of this, the key unit to inspect is usually cockpit.socket, not a continuously running cockpit.service.

sudo systemctl status cockpit.socket
sudo ss -ltnp | grep ':9090'

Look for an active/listening socket and a listener bound to port 9090. If the unit is missing, Cockpit may not be installed. On a SLES release whose enabled repositories provide the Cockpit pattern, SUSE documents installing it with:

sudo zypper refresh
sudo zypper in -t pattern cockpit

If Zypper reports that the pattern cannot be found, check the product, service pack, enabled modules, repository status, and support entitlement with your SUSE administrator. Do not add an unrelated third-party repository just to make the command succeed. After confirming Cockpit is installed, enable and start its socket:

sudo systemctl enable --now cockpit.socket
sudo systemctl status cockpit.socket

The --now option starts the socket immediately as well as enabling it for future boots. If systemd reports a failed unit, inspect the exact error before repeatedly restarting it:

sudo journalctl -u cockpit.socket -b --no-pager
sudo journalctl -u cockpit.service -b --no-pager

3. Allow Cockpit through the active firewall zone

An active listener can still be unreachable if the host firewall drops the connection. SLES uses firewalld for firewall management in current releases. First identify the active zone and the interface assigned to it:

sudo firewall-cmd --get-active-zones

Then add the named Cockpit service to the zone that contains the management interface. Replace public with the actual zone reported on your host:

sudo firewall-cmd --zone=public --add-service=cockpit --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --query-service=cockpit

The final command should report yes. If the network interface is in a different zone, opening the service in public will not fix that interface's rules. SUSE's Cockpit documentation uses the cockpit firewalld service; opening the named service is preferable to opening all traffic or disabling the firewall. Also check cloud security groups, perimeter firewalls, VPN policies, and network ACLs if the host rule is correct but the client still times out.

If your SLES image uses a different firewall management setup, follow the policy for that system instead of applying firewalld commands blindly. Do not flush firewall rules or disable the firewall on a remotely administered production server: that can expose services and may interrupt your current management path.

4. Separate a connection failure from a certificate or login problem

Once the login page loads, the network path to Cockpit is working. Cockpit normally expects browser connections to use HTTPS and presents a TLS certificate. A warning for a self-signed certificate or a name mismatch does not mean the socket is down. For a lab host, verify the fingerprint through a trusted channel before accepting the warning. For managed systems, install a certificate whose subject name matches the hostname administrators use and whose chain is trusted by their browsers.

If the login page appears but credentials are rejected, verify the username, password, account state, and the server's authentication policy. Cockpit generally authenticates against system accounts; it is not a separate user database. Do not put passwords in commands or logs while troubleshooting. If the page loads but the interface stays blank or disconnects after login, inspect the browser's developer console and recent Cockpit logs. A reverse proxy can also cause failures if it does not support WebSocket connections or forwards the wrong protocol or host information.

5. Review logs and proxy settings when the basics pass

Capture a short log window while making one fresh connection attempt:

sudo journalctl -u cockpit.socket -u cockpit.service --since "10 minutes ago" --no-pager

Look for bind errors, permission or certificate errors, and messages that line up with the test time. If the server listens locally but a remote client cannot connect, investigate the network path and firewalld zone before changing Cockpit configuration. If direct access works but access through a proxy fails, temporarily compare through a permitted direct route, then review the proxy's WebSocket upgrade support and forwarded headers. Avoid changing Cockpit's origin or TLS settings as a first step; incorrect proxy trust settings can weaken security.

Verify the repair

After making one change at a time, verify these outcomes:

• systemctl status cockpit.socket shows the socket active and listening.
• The SLES host has a listener on the expected port, normally TCP 9090.
• The firewall rule is present in the zone assigned to the management interface.
• The client can reach the server at https://SERVER_IP:9090 and sees the Cockpit sign-in page.
• After authentication, the page remains connected and the recent journal contains no matching startup or connection error.

If the socket is active and local checks succeed but remote TCP tests still time out, the remaining fault is likely outside Cockpit itself, such as an upstream firewall, network route, DNS record, or VPN rule. If the service fails on an otherwise supported SLES system, save the unit status and journal output and check the SUSE documentation or support channel for the exact service-pack configuration rather than applying fixes intended for another distribution.

Official references

• SUSE: Administering SUSE Linux Enterprise Server Using Cockpit
• Cockpit Project: Startup and systemd socket activation
• Cockpit Project: TCP port and address
• Cockpit Project: HTTPS and certificates
• Cockpit Project: Troubleshooting FAQ
• SUSE: SLES 15 SP5 firewall configuration and firewalld zones