Can't log in to server using SSH keys

[Mugane]

Login:

We can't log in to Cockpit using SSH keys.

Basic password authentication is disabled across all resources and users are configured with public keys and random strings for passwords that are not known by anyone and not saved anywhere. Users with admin privileges are able to sudo to accomplish tasks. Cockpit requires a login/password combination. This does not exist in our configuration. Users log in with keys via ssh and enter their key username and key password on terminal login.

When I set up a SSH tunnel to a Cockpit server I see the same Cockpit login screen, but my key password is rejected. Is there a way to fix this? Or to configure Cockpit to somehow allow login when there is no known password and server password authentication is disabled? Turning it on is not an option.

[martinpitt]

At least in the default configuratrion, the very first cockpit login has to happen via some auth mechanism that browsers understand: user/password, certificate/smartcard , or Kerberos. Browsers don't speak SSH, so it's not generally possible to directly do what you wnat.

What you can do in your case is to set up a "bastion host" -- some unprivileged VM or container with user/password which gives you an initial Cockpit session from where you connect to "real" machines via SSH, see https://cockpit-project.org/guide/latest/authentication.html#secondary-auth. The cockpit/ws container can also be configured to receive a specific ssh private key and then use the login page password to decrypt it -- but of course that doesn't work for multiple users.

[Mugane]

I don't think it matters if it's a whole machine or a container, both the security issue and the complexity issue will be independent dealbreakers for practically every user. If you have to set up a bypass for a security feature (no password auth) then there is no point having it at all. If a user has to set up any kind of vm/container just to access a single resource, it simply won't happen. Only the authors of a tool would generally consider it to be important enough to warrant either of these compromises.

I assume you're referring to no way to sensibly select a private key? What would prevent a file upload field on the login form? Then users could set up a tunnel if they wanted to maintain the security level offered by cryptographic keys for the transport layer versus SSL/TLS. Even without a tunnel, uploading an ephemeral key is significantly better than storing a private key on a host machine with it's public key (on the same machine as suggested in the SSH section you linked) which also defeats the purpose of using them in the first place.

[martinpitt]

Please take a look at the Client flatpak 😁

[Mugane]

As noted, that is not available for non-linux clients, and is therefore a limited workaround (not generally applicable, not useful in any of the cases I have encountered). Please consider the upload option.

[eluinstra]

You can also install the CockpitClient flatpak in WSL.

[Mugane]

@eluinstra it really doesn't even matter which system we're on - the servers themselves do not have a user/pass login method and we are never going to compromise on this, especially for the sake of using a small management utility.

[mac2net]

I use a Fedora instance on Lima (which runs on a Mac) to access Cockpit on a server over SSH.

[Mugane]

I think we can generally agree that expecting users to switch operating systems in order to use a utility is not a practical solution.

[mac2net]

That's not what is happening! Lima stands for Linux Machines.
Install Brew
Intall Lima
Install the bridge networking bit
Add something like this to the Fedora yaml

#!/bin/bash
dnf -y groupinstall "Headless Management"  --with-optional 
dnf -y install cockpit-navigator cockpit-pcp
dnf -y install firewalld
dnf -y install neofetch 
systemctl enable cockpit.socket
systemctl start cockpit.socket
systemctl unmask firewalld
systemctl start firewalld
systemctl enable firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=cockpit
firewall-cmd --reload
sed -i '2s/^/# /' /etc/cockpit/disallowed-users
echo "my password" | passwd --stdin root

When the system is ready I a few minutes, get into the shell and find out the VMs network IP address.
Login to "my-fedora-on-a-mac":9090 and add the server ip address and it will 22 into it.

Also, you can run this on another Mac and use that to jump into the Fedora machine via 22.

[Mugane]

Nope, just not simple enough to fold in to the management process for devs. Without a key upload it's just not going to happen.

[jo-bitsch]

I was thinking about logging in via webauthn/fido2, which is something that the browser as well as ssh should understand.

To use a webauthn signature from the browser in the ssh session, you would probably need webauthn signatures from openssh: https://github.com/openssh/openssh-portable/blob/88351eca17dcc55189991ba60e50819b6d4193c1/PROTOCOL.u2f#L222

I think the signature type [email protected] are currently not yet implemented in libssh, so this might require getting some preconditions in place for the C-bridge. Similarly, the openssh client does not yet support injecting a signature received from a webserver, so this might also not be that easy to add to ferny in the Python-bridge. Maybe this could be achieved though by providing an alternative SecurityKeyProvider (see man ssh_config).

That being said, this would enable the use of secure hardware tokens and potentially even passkeys for weblogin and for remote SSH connections in cockpit, which would be pretty neat usability-wise and far better from a security perspective than passwords.

webauthn signatures has very little adoption though on the net, so far.

The only useful references I saw are:

• https://lists.archive.carbon60.com/openssh/dev/80197
• https://staff.sharcnet.ca/tyson/webauthnkey.html
• https://github.com/openssh/openssh-portable/blob/88351eca17dcc55189991ba60e50819b6d4193c1/regress/unittests/sshsig/webauthn.html
• I think https://docs.blink.sh/advanced/webauthn might use it under the hood, because to my understanding passkeys strictly require a web origin.

[jo-bitsch]

Just checking through the openssh source code, it seems like the SecurityKeyProvider is not able to create this type of signature yet as the sk_sign_response cannot hold the necessary attributes, however, through implementing the ssh_agent protocol, you can return a complete signature, so this might be possible after all, without fiddling too much in the internals of an ssh implementation.