The most common way to use Cockpit is to just log directly into the server that you want to access. This can be done if you have direct network access to port 9090 on that server.

By default the cockpit web service is installed on the base system and socket activated by systemd. In this setup access is controlled by a cockpit specific pam stack, generally located at /etc/pam.d/cockpit. By default this is configured to allow you to login with the username and password of any local account on the system. You can also setup a Kerberos based SSO solution or certificate/smart card authentication.

You can also disable authentication schemes to enforce authentication policies, or to suppress undesired browser GSSAPI authentication dialogs.

The web server can also be run from the cockpit/ws container. If you are running cockpit on a container host operating system like Fedora CoreOS this will be the only supported mode. In this setup, cockpit establishes an SSH connection from the container to the underlying host, meaning that it is up to your SSH server to grant access. To login with a local account, sshd will need to be configured to allow password based authentication. Alternatively you can setup a Kerberos based SSO solution.

Like sshd, cockpit can be configured to limit the number of concurrent login attempts allowed. This is done by adding a MaxStartups option to the WebService section of your cockpit.conf. Additional connections will be dropped until authentication succeeds or the connections are closed.

It is also possible to log into a secondary server without opening a session on the primary server. This is useful if you are not actually interested in the primary server and would only use it because you do not have direct network access to the secondary server.

In this case, cockpit-ws still runs on the primary server, but the credentials from the login screen are directly used with SSH to log into the secondary server given in the "Connect To" field of the login screen.

Thus, the PAM configuration and accounts on the primary server don't matter at all. Often, the only purpose of the primary server is to sit on the boundary of your network and forward connections to internal machines.

In this case, the login page will prompt you to verify unknown SSH keys. Accepted keys will be remembered in the local storage of your browser.

Once you have a session on the primary server, it is possible connect to additional servers by using the host switching UI of the Cockpit Shell. This is useful if you have direct network access to the primary server, but not to the secondary server.

On the command line, you would log into the primary server and then use SSH to log into the secondary one. Cockpit does just the same, and uses SSH to log into the secondary server. Instead of running a interactive shell there, however, it starts a cockpit-bridge process.

Warning: Unlike with SSH on the command line though, this will also load and use the Cockpit pages (i.e. JavaScript) from the remote machine, which means that the remote machine can execute arbitrary code on your primary and all other connected secondary machines. Hence, only connect to machines which you trust.

Due to this security risk, this host switcher functionality is disabled by default, except on long-term stable Linux distributions (Red Hat Enterprise Linux 9, Debian 12, and Ubuntu 22.04/24.04 LTS). If you are comfortable with the security implications, you can enable it manually with the AllowMultiHost option in cockpit.conf.

These servers will need to be running an SSH server and be configured to support one of the following authentication methods.