Decided to take a look at the new Cockpit system and installed nethserver-cockpit this morning. However, I’m not able to log in–it just gives a “Permission denied” error when I try to log in as admin:
System log shows this:
Feb 14 18:30:14 neth systemd: Started Cockpit Web Service.
Feb 14 18:30:14 neth cockpit-ws: Using certificate: /etc/cockpit/ws-certs.d/99-nethserver.cert
Feb 14 18:30:14 neth cockpit-ws: cockpit-session: user account access failed: 7 admin: Authentication failure
I’m quite certain that I typed the password correctly. What else should I check?
I think it’s a good idea… sometimes I need to enable some “normal” users to access to server manager because they want to manage themselves their server.
Don’t think I do–unless you install self-service password, the server manager is the only way for a user to change his password. Given that, at least by default, everyone should have access. But in any event, SSH access and the ability to log in to the new server manager have no apparent relationship with each other, so controlling the one with a checkbox marked the other way is far from intuitive.
@federico.ballarini got it right: a user can access cockpit only if he/she has a shell which is listed inside /etc/shells.
In NS the default shell for a user is /usr/libexec/openssh/sftp-server.
I’m already aware of this behavior and I think it should be changed, but what is the good solution?
We have a couple of different changes:
allow the selection of extra shell on user creation: /bin/bash, /bin/false, /usr/libexec/openssh/sftp-server
just create a template for /etc/shells and add /usr/libexec/openssh/sftp-server (I think we can add it to excellent user delegation effort from @stephdl)
What do you think?
I also would like to point out that, thanks to @davidep work, now a user can change his own password from Cockpit even if the Account Provider is remote (LDAP or AD).
Why not to develop an user area on port 443 used for change “customizable” user settings like name, password, general information and have a recap of you accessible folders and your email addresses?
So that’s a requirement that’s baked into Cockpit? That’s… strange.
If we’re going to have a by-user toggle for access to the Cockpit UI, that toggle needs to say something that clearly indicates what it controls. IMO, we can’t simply document around this; the GUI itself needs to say that it controls access to Cockpit.
If there’s going to be a separate password-change page (which is something I’ve argued for for a while), then there’s no reason that ordinary users need access to Cockpit, but all admins should have access by default.
If password change is going to stay in the server manager, then all users, at least by default, need to have access to it.
I don’t see that we particularly need to change the current behavior of the server manager in this regard–include password change in there, have no user-level access control, and the user’s permission level will control what he can do in there (i.e., admins can do admin-y stuff, other users can just change password and perhaps update their own profiles). I guess the least intrusive way to do that would be to add sftp-server to /etc/shells. Though that’s leaving the question of why sftp-server is the default anyway–it seems like /bin/false would have been a better choice to prevent users from logging in via SSH (or even the console).
Because the normal web server runs with unprivileged user (apache) and there is no secure and simple way to achieve the goal.
Also it will be another software to maintain.
