Today, I wanted to add Cockpit to the Pi 500+ Ubuntu install, but I didn't want to sit at the desk where I'd placed the keyboard.
When I tried to ssh into the Pi, I kept getting connection refusals, which I thought was odd. I ended up having to spend some time at the Pi keyboard, investigating why I couldn't connect to it on port 22.
I found out that I'd never installed ssh! I could've sworn I did, but maybe it was the Pi OS install that I installed it.
So, after I installed it, I installed Cockpit (I wanted to try it instead of using WebMin). I then found that, after the install, when logged into Cockpit, it was only allowing my user limited administrator access. It gave the option to gain full admin privileges, but when I clicked it, it gave an error that sudo couldn't be leveraged to escalate privileges. When I googled that error, I found that one of the suggested fixes was to add your user to the wheel group. My Pi didn't have a wheel group, so I had to create one. Once I created the wheel group, I had to add my user to that group.
I then double-checked my research and found a link to a Cockpit bug report of this exact issue back in October 2025. The issue was that sudo was recently redeveloped in Rust code, and apparently does not support the --askpass flag, which is used by Cockpit. The fix is to run the following (it's the non-Rust sudo implementation, which is still availabe:
# update-alternatives --set sudo /usr/bin/sudo.wsNow, I've Ubuntu all over the house on various machines, most of them running Cockpit. I've not seen this issue before, and I've done a bunch of recent installs of Ubuntu 25.10. In fact, I installed Cockpit on my docker container host, today. It didn't exhibit this issue/bug. I'm wondering why I'm only now seeing it. I'm glad there's a workaround, though.