How to Install Cockpit on Ubuntu 18.04

By Ghulam Qadir, Alibaba Cloud Tech Share Author. Tech Share is Alibaba Cloud’s incentive program to encourage the sharing of technical knowledge and best practices within the cloud community.

Cockpit is a server manager that makes it easy to administer your GNU/Linux servers via a web browser. It makes Linux discoverable, allowing sysadmins to easily perform tasks such as starting containers, storage administration, network configuration, inspecting logs and so on.

Cockpit provides convenient switching between the terminal and the web tool. A service started via Cockpit can be stopped via the terminal. Likewise, if an error occurs in the terminal, it can be seen in the Cockpit journal interface. Using Cockpit you can monitor and administer several servers at the same time. Just add it easily and your server will look after its buddies.

Cockpit is released under the LGPL v2.1+, and it is available for Redhat, CentOS, Debian, Ubuntu, Atomic, and Arch Linux. Cockpit is compatible and works well with Alibaba Cloud Elastic Compute Service (ECS) servers. In this tutorial, I will be installing Cockpit on an ECS with Ubuntu 18.04 LTS installed on it. Until Ubuntu 18.04 matures and is included in Alibaba Cloud’s library of operating system images, we can upgrade Ubuntu 16.04 to Ubuntu 18.04 by using the do-release-upgrade utility.


  1. You should set up your server’s hostname.
  2. Access to VNC console in your Alibaba Cloud or SSH client installed in your PC.

After completing the prerequisites, log in as root user with your root username & password via SSH client (e.g. Putty) or VNC console available in your Alibaba Cloud account dashboard.

Install Cockpit on Ubuntu 18.04

sudo apt update

Install the Cockpit package.

sudo apt -y install cockpit

Start and Enable the Cockpit.

sudo systemctl start cockpit.socket
sudo systemctl enable cockpit.socket

Working with Cockpit


Cockpit uses a self-signed SSL certificate for secure communication. So, you need to add an exception in your browser to access the Cockpit.

Log in with your local user account. In my case it is gqadir.

If the user is a non-privileged user and has sudo access, then tick mark Reuse my password for privileged tasks.

We must now insert our credentials in the related input fields and click on the Log In button. Once logged in we will be redirected to the main cockpit page:

Let’s take a look at it. The main page section shows us some information about the machine we are running on, as the hardware, hostname, operating system and system time. In this case I am running Ubuntu on a virtual machine, therefore the value of the hardware section is QEMU Standard Pc.

We also have a dropdown menu which let us perform a power option on the system as restart or shutdown. On the right we can see some graphs which let us monitoring crucial system activities, in order: CPU and memory usage, disk activity and network traffic.

The Logs Section

To access detailed information about a log message, all we have to do is to click on the corresponding row: we will be redirected to a page containing the log details.

The Storage Section

We could inspect a specific drive by clicking on the related section on the right in the Drives box: we will also be able to create a new partition table (if some conditions are respected — the disk must not be mounted, for example) on the specified drive: the operation will erase all the data on it.

The Network Section

The Accounts and Services Sections

In the services section, we will be presented with an overview of system daemons and targets. The web interface grants us the ability to start, stop, enable or disable each service, showing us its current state. Thanks to cockpit, we can also easily manage systemd targets (the equivalent of classic system runlevels), sockets and timers.

Let’s now look at how we can configure Cockpit for our applications.

1. Cockpit Configuration File — cockpit.conf

Note: The port that cockpit listens on cannot be changed in this file. To change the port change the systemd cockpit.socket file.


By default, cockpit will not accept crossdomain websocket connections. Use this setting to allow access from alternate domains. Origins should include scheme, host and port, if necessary.

Origins =


Configure cockpit to look at the contents of this header to determine if a connection is using tls. This should only be used when cockpit is behind a reverse proxy, and care should be taken to make sure that incoming requests cannot set this header.

ProtocolHeader = X-Forwarded-Proto


Set the browser title for the login screen.


When set to true the Connect to option on the login screen is visible and allows logging into another server. If this option is not specified then it will be automatically detected based on whether the cockpit-ssh process is available or not.


When set to true cockpit will require users to use the Connect to option to specify the host to log into.


Same as the sshd configuration option by the same name. Specifies the maximum number of concurrent login attempts allowed. Additional connections will be dropped until authentication succeeds or the connections are closed. Defaults to 10.

Alternatively, random early drop can be enabled by specifying the three colon separated values start:rate:full (e.g. “10:30:60”). Cockpit will start refusing authentication attempts with a probability of rate/100 (30%) if there are currently start (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches full (60).


If true, cockpit will accept unencrypted HTTP connections. Otherwise, it redirects all HTTP connections to HTTPS. Exceptions are connections from localhost and for certain URLs (like /ping). Defaults to false.


The root URL where you will be serving cockpit. When provided cockpit will expect all requests to be prefixed with the given url. This is mostly useful when you are using cockpit behind a reverse proxy, such as nginx. /cockpit/ and /cockpit+ are reserved and should not be used. For example /cockpit-new/ is ok. /cockpit/ and /cockpit+new/ are not.


The kind of log messages in the bridge to treat as fatal. Separate multiple values with spaces. Relevant values are: criticals and warnings.



This is the url that cockpit will redirect the users browser to when it needs to obtain an oauth token. Cockpit will add a redirect_uri parameter to the url with the location of where the oauth provider should redirect to once a token has been obtained.


When an oauth provider redirects a user back to cockpit, look for this parameter in the querystring or fragment portion of the url to find an error message. When not provided it will default to error_description


When an oauth provider redirects a user back to cockpit, look for this parameter in the querystring or fragment portion of the url to find the access token. When not provided it will default to access_token

2. Cockpit Web Service — cockpit-ws

Users or administrators should never need to start this program as it automatically started by systemd(1) on bootup.

cockpit-ws [ — help] [ — port PORT] [ — no-tls] [ — local-ssh] [ — address ADDRESS]

Transport Security

The .cert file should contain at least two OpenSSL style PEM blocks. First one or more BEGIN CERTIFICATE blocks for the server certificate and intermediate certificate authorities and a last one containing a BEGIN PRIVATE KEY or similar. The key may not be encrypted.

If there is no TLS certificate, a self-signed certificate is automatically generated using openssl and stored in the 0-self-signed.cert file.

When enrolling into a FreeIPA domain, an SSL certificate is requested from the IPA server and stored in 10-ipa.cert.

To check which certificate cockpit-ws will use, run the following command.

$ sudo remotectl certificate

If using certmonger to manage certificates, following command can be used to automatically prepare concatenated .cert file:

getcert request -f ${CERT_FILE} -k ${KEY_FILE} -D $(hostname --fqdn) –
C "sed -n w/etc/cockpit/ws-certs.d/50-from-certmonger.cert




In addition the XDG_DATA_DIRS environment variable from the XDG basedir spec can be used to override the location to serve static files from. These are the files that are served to a non-logged in user.

3. Remote Access Configuration — remotectl

remotectl {COMMAND} [OPTIONS…]


Manage Cockpit’s SSL certificate. If used without options will check if cockpit has a valid certificate without making any changes.

— ensure Ensure that a certificate exists and can be loaded. Certificate will be created if it does not already exist.

— user username The unix user that should own the certificate. Only takes effect if used with — ensure.

— group groupname The unix group that should read the certificate. Only takes effect if used with — ensure.

If any additional arguments are given, they are treated as files that should be combined to create a certificate file. If the combined files validate, they will be saved in the appropriate location using the name of the first file given with the extension changed to .cert. For example:

remotectl certificate server.pem chain.pem key.pem

will result in server.cert. If server.cert already exists it will be overwritten.


4. Cockpit Host Bridge — cockpit-bridge

This program is not routinely run by users or administrators. It is in the $PATH so that Cockpit can find it when connecting between hosts. However there are some diagnostics available when running from the command line.

cockpit-bridge [ — help] [ — packages]




Follow me to keep abreast with the latest technology news, industry insights, and developer trends.