Cockpit Authentication

Primary server authentication

While cockpit allows you to monitor and administer several servers at the same time, there is always a primary server your browser connects to that runs the Cockpit web service (cockpit-ws) through which connections to additional servers are established. See this diagram for how it works.

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 or you can setup a Kerberos based SSO solution.

The web server can also be run from the cockpit/ws docker container. If you are running cockpit on an Atomic Host this will be the default. 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.

Secondary server authentication

Once you are able to login to the primary server you will be able to connect to additional servers. These servers will need to be running an SSH server on port 22 and be configured to support one of the following authentication methods.

Password

The target server will need to have password based authentication enabled in sshd. When this is setup for the first time, Cockpit will ensure that the user connected to primary server has the same password on the secondary server.

Kerberos

The target server will need to be a member of the same domain as the primary server and your domain must be whitelisted in your browser. See the SSO documentation for how to set this up.

Public key

When you successfully log into the primary server, an ssh-agent is started. The following keys are then preloaded into the ssh-agent provided they are supported by your SSH version, present, with the correct permissions, and either unencrypted or encrypted with the same password that was used to login.

~/.ssh/id_rsa
~/.ssh/id_dsa
~/.ssh/id_ed25519
~/.ssh/id_ecdsa

Cockpit provides an interface for loading other keys into the agent that could not be automatically loaded.

The target server will need to have public key authentication enabled in sshd, and the public key you wish to use must be present in ~/.ssh/authorized_keys.

Note that when a user is authenticated in this way the authentication happens without a password, as such the standard cockpit reauthorization mechanisms do not work. The user will only be able to obtain additional privileges if they do not require a password.