Cockpit: 3 incorrect password attempts

[kaysond]

Every time I log into cockpit for the first time in a while, I get a syslog error about incorrect password attempts:

administrator : 3 incorrect password attempts ; TTY=unknown ; PWD=/run/user/1000 ; USER=root ; COMMAND=/usr/bin/cockpit-bridge --privileged

PRIORITY | 1
-- | --
SYSLOG_FACILITY | 10
SYSLOG_IDENTIFIER | sudo
_AUDIT_LOGINUID | 1000
_AUDIT_SESSION | 7103
_BOOT_ID | 6049c6d2d70c4cc194752d15aeb7fc56
_CAP_EFFECTIVE | 3fffffffff
_CMDLINE | /usr/bin/sudo -A cockpit-bridge --privileged
_COMM | sudo
_EXE | /usr/bin/sudo
_GID | 1000
_HOSTNAME | fserver
_MACHINE_ID | efa2f5b497b04141b4124e8ececb5c38
_PID | 25593
_SELINUX_CONTEXT | unconfined
_SOURCE_REALTIME_TIMESTAMP | 1541383997850537
_SYSTEMD_CGROUP | /user.slice/user-1000.slice/session-7103.scope
_SYSTEMD_INVOCATION_ID | 51275133b36e4feb96eb890e6e4f72e7
_SYSTEMD_OWNER_UID | 1000
_SYSTEMD_SESSION | 7103
_SYSTEMD_SLICE | user-1000.slice
_SYSTEMD_UNIT | session-7103.scope
_SYSTEMD_USER_SLICE | -.slice
_TRANSPORT | syslog
_UID | 0
__CURSOR | s=0510ac448f4945258123ab4fb0b4c510;i=178c44a;b=6049c6d2d70c4cc194752d15aeb7fc56;m=17e9fbe5c85;t=579e16da78447;x=2822deed74d9f4fb
__MONOTONIC_TIMESTAMP | 1643357559941
__REALTIME_TIMESTAMP | 1541383997850695

[martinpitt]

Apparently your user doesn't have sudo privileges, but you checked

[x] Use my password  for privileged tasks

? Then cockpit will attempt to run the privileged bridge through sudo, apparently that failed.

[kaysond]

My user does have sudo privileges. And actually I just logged in right now, and did not check that box, and still got the error.

[kurankat]

I am having this exact issue with users that have sudo privileges on both Ubuntu 18.04 and Debian 9.

[kurankat]

Some associated error messages. I have substituted 'user' for my username and obscured hostname and ip addresses.

Dec 17 06:45:34 host sshd[18905]: Connection from my.ip.address port 26857 on server.ip.address port XXXX
Dec 17 06:45:34 host sshd[18905]: Postponed publickey for user from my.ip.address port XXXX ssh2 [preauth]
Dec 17 06:45:34 host sshd[18905]: Accepted publickey for user from my.ip.address port XXXX ssh2: RSA SHA256:OBSCURED
Dec 17 06:45:34 host sshd[18905]: pam_unix(sshd:session): session opened for user user by (uid=0)
Dec 17 06:45:34 host systemd-logind[373]: New session 4395 of user user.
Dec 17 06:45:34 host systemd: pam_unix(systemd-user:session): session opened for user user by (uid=0)
Dec 17 06:45:34 host sshd[18905]: User child is on pid 18914
Dec 17 06:45:35 host sshd[18914]: Starting session: command for user from my.ip.address port XXXX id 0
Dec 17 06:45:35 host polkitd(authority=local): Registered Authentication Agent for unix-session:4395 (system bus name :1.204 [cockpit-bridge], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Dec 17 06:45:54 host polkit-agent-helper-1[18939]: pam_unix(polkit-1:auth): authentication failure; logname= uid=1000 euid=0 tty= ruser=user rhost=  user=user
Dec 17 06:45:55 host polkitd(authority=local): Operator of unix-session:4395 FAILED to authenticate to gain authorization for action org.freedesktop.policykit.exec for unix-process:18915:24258383 [cockpit-bridge] (owned by unix-user:user)
Dec 17 06:45:55 host pkexec[18936]: user: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/run/user/1000] [COMMAND=/usr/bin/cockpit-bridge --privileged]
Dec 17 06:45:55 host sudo: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty= ruser=user rhost=  user=user
Dec 17 06:46:02 host sudo:      user : 3 incorrect password attempts ; TTY=unknown ; PWD=/run/user/1000 ; USER=root ; COMMAND=/usr/bin/cockpit-bridge --privileged

[awwong1]

I too am having this issue with from a fresh install on Ubuntu 18.04.

alexander : 3 incorrect password attempts ; TTY=unknown ; PWD=/run/user/1000 ; USER=root ; COMMAND=/usr/bin/cockpit-bridge --privileged

EDIT: This goes away when I check the box labeled Reuse my password for privileged tasks

[deryni]

@martinpitt Is your belief here that this _should not_ be happening when the checkbox is not used at login time?

That is, that cockpit should not be attempting to launch the privileged bridge in that situation at all? (Which would mean that password-less sudo, etc. access to admin commands will not be usable for cockpit functionality?)

[martinpitt]

@deryni: Yes, it is, there is clearly a bug.

[whisky23]

Is there any solution or workaround for this bug?
I've got the same problem.

[BUMPRW]

Also having the same problem on Fedora Server V30

[alessandrobelli]

Same problem with Ubuntu 18.04 LTS

[gregmclearswift]

So my understanding of this is that the shell package manifest.json (/usr/share/cockpit/shell/manifest.json on RHEL7) is trying to launch cockpit-bridge with privileges, first via pkexec, the second via sudo -A.

I believe that when the user logs into cockpit without checking "Reuse my password for privileged tasks", the user's password isn't retained by cockpit-askpass, so when cockpit does the equivalent of
SUDO_ASKPASS=/usr/libexec/cockpit-askpass sudo -A cockpit-bridge --privileged sudo isn't supplied with the correct password so will fail to authenticate 3 times.

This is really bad for systems complying to STIG rules as it means that whenever a user logs into cockpit they are locked out of their account due to 3 incorrect password "inputs".

The workaround I'm currently trying out is to essentially revert the commit that changed sudo -n to sudo -A in that file by using an override (YMMV):

# cat /usr/share/cockpit/shell/override.json 
{
    "bridges": [
        {
            "match": {
                "superuser": null
            },
            "spawn": [
                "/usr/bin/pkexec",
                "--disable-internal-agent",
                "cockpit-bridge",
                "--privileged"
            ]
        },
        {
            "match": {
                "superuser": null
            },
            "spawn": [
                "/usr/bin/sudo",
                "-n",
                "cockpit-bridge",
                "--privileged"
            ]
        }
    ]
}

However this _really doesn't_ seem like the right thing to do. So feedback from someone that knows more about this than I do would be appreciated.

[martinpitt]

@mvollmer: FYI, this is another aspect of your auth rework.

[mvollmer]

Yes, we need to a way to not attempt sudo on every login.

[Debilski]

Are there any updates to a proper fix or a nicer workaround? The override.json with sudo -n will still send an annoying email where sudo complains that a password is required.

[mvollmer]

This should be fixed in Cockpit 219.

Now Cockpit should only run "sudo" when Cockpit has a password for it. Any failure should thus be a "real" failure and indicate that the user wanted admin access but it wasn't granted.
(Previously, Cockpit would implement the case of "I don't want admin access" by running sudo anyway but giving it the empty string as the password. Thus you would get a lot of "fake" failures.)

However, Cockpit still runs sudo -v -n on every login to figure out whether the user is ever able to gain superuser privileges. Is that a problem as well? I do get a journal entry for it, which might mean that other people might still get the emails...

[Debilski]

Ah, should’ve looked into the Debian backports. For me this seems to have stopped the emails. Thanks.

[mvollmer]

For me this seems to have stopped the emails.

Nice. Let's close this issue then. Please reopen if you still see the problem with Cockpit 219 or later.

[kaysond]

Thanks all for following through with this!