I have “normal users” ssh/sftp access set to “no access”.
/etc/cockpit.allow only contains “root” and “domain admins”.
The issue:
Normal users can still log in to the Cockpit on port 9090. And even though ssh/sftp access is turned off for normal users, they can click on Terminal in cockpit and get a command prompt.
Ideally I’d like for cockpit to only be accessible to root and domain admins as the cockpit.allow file seems to indicate is what should be happening, but failing that, I’d like a way to disable the Terminal function in Cockpit.
/usr/share/cockpit/systemd/override.json already has terminal set to null, but this seems to be a different terminal than the one used in the Nethserver cockpit?
Short of deleting /usr/share/cockpit/systemd/terminal.html.gz I haven’t found a way to do this.
The 7.7 release notes say “Only users with enabled shell can access the new Server Manager.”, but that doesn’t seem to be the case on my server.
I’d like to retain the user-settings page for normal users so they can change their passwords, while at the same time blocking login to the cockpit on port 9090 for the same users. Mostly because of the terminal issue, but also because normal users don’t have any need to see the information in cockpit:9090.
I disabled the GUI terminal function for now by “chmod 600 terminal.html.gz”. This allows it to still work for root login should I need it, but gives all other users a “not found” message.
It does seem like a strange choice to allow blocking ssh logins, but giving the users practically the same thing through the gui anyway.
There’s a self-service-password module for users to change their passwords. You may use it instead of the user settings page and disable shell access so no normal user can login to the server manager anymore.
I actually think I’ve come across that one before.
For now I’m just going to leave it with the terminal disabled through chmod. I made a script that uses inotifywait to check for permissions changes on the file, and will reset them back to 600 if they change.
The self service password module is a solution to my issue, though, so I’ll mark your response as the solution for posterity.