Thank you, for your Explanation, but it declares not why posix admins dont have this access anymore.
Indeed i have no posix “users” but two posix-admins (administrator,wheel). The first of them was created within nethserver/centos installer, the second afterward by myself. Since this, both users has access to server-manager and over ssh - until few days.
(i havent accidentally enabled this).
The server-manger has no option to reverse this - unless ich give ssh access to all users, then the posix-admins have server-manager and ssh access and again.
Which is the suggested (nethserver-like) way to give access back to posix-admins?
Sorry, maybe I wasn’t clear enough.
The enabled shell override
adds a “stricter mode” to sshd_config.
Match Group "root,domain admins@domain.local"
ForceCommand none
AllowTCPForwarding yes
X11Forwarding yes
Match All
ForceCommand internal-sftp
AllowTCPForwarding no
X11Forwarding no
Now your posix users can’t login anymore.
Why not? If you want the shell override you need to set the normal users to “SSH+SFTP” to be able to login again.
This just sets the sshd_config back to the settings where your posix users are allowed again but enables account provider users to login by changing their shell.
If you need the shell override, allow normal users to ssh or disable the shell override.
If you want the posix users to login but the account provider users not you need to disable the shelloverride.
If that’s not possible I recommend to change the posix users to account provider users and allow them by group in UI.
If that’s not possible we can think about a custom template…
Thank you again. I searched/expected this setting in system > ssh instead in system > settings but your screen picture was helpful.
So there are now three places for setting ssh access options.
system > settings - for enable/disable new/old ssh/sftp behavior
system > ssh - for managing ssh / sftp users/groups (and other ssh options)
system > users - for enabling/disabling ssh per user
O.k.
What was the intention to create this new option? The possibility to have separate groups for ssh/sftp enabling? Indeed, it seems to be a good idea for this…
But, In my opinion - the new option has also unlucky side effects.
Enabling ssh for (all) normal users to enabling ssh and server-manager for posix-admins (again) is - at least for me - no option. What if the account provider service is bad/offline? Root ssh login should always/better be off (normally) - in my opinion.
And - with the new option you loose also the (previous) possibility to disable ssh access for account provider admins. In my opinion, directory admins should not have (generally) have ssh access.
I assume yes and the new user settings page.
To be able to login to the server manager or the new user settings page login page, users need the shell enabled. To make this possible, you need the shell override.
The shell override enables the shell for all domain users and therefore sshd is used to set permissions by groups but posix groups are not included.
OK, in this case without root and need for system users to login you need a custom template or disable shell override completely but is it a common case? The idea is to not include rarely needed functions. @giacomo@stephdl should we include an option to allow posix groups? Or at least split up the fragments to allow a better custom template?
To create the custom template you need to copy a témplate fragment (not optimal but I see no other way).
Edit /etc/e-smith/templates-custom/etc/ssh/sshd_config/70Restricted2Sftp and add your group(s), you have to separate by comma. I already added the posix test group to allow the posix user test.
$OUT .= qq(Match Group "$match_group_exp,test"\n);
Now your sshd_config should include group test to be allowed to SSH/SFTP even if permission for normal users is no access. There are more options like DenyUsers, AllowUsers and DenyGroups:
Thank you very much for the great description!
I am already thinking about an own custom template but your description is so muchbetter than mine.
I hope my description was not to ambiguous and in case my less language knowledge makes my postings sounds unfriendly - let me make it clear - the nethserver project is really great and all supporters and developers make a really great “job”. In deutscher Sprache würde mir das viel leichter fallen, aber der Inhalt dieses Forums soll ja verständlicherweise allen zugänglich sein.
One comment about “The idea is to not include rarely needed functions…should we include an option to allow posix groups?” (where ca i cite here?):
I dont know the current centos/nethserver installation procedere (my last installation was summer 2019) but - as i remember - last summer was the creation of a posix admins a part of the basic installation procedere - with ssh and server-manager access.
Disabling posix-admins within nethserver (in general) increased the distance between the underlying centos system and nethserver (in my opinion).
Hmm, i unterstand. Seems not so easy to unify this different approaches(?).
As i remember, the first (during install) created admin-user has access to server-manager instantly.
Later created posix users must be set to additional groups:
As i know, “wheel” users in centos has anyway the ability to sudo - and thereby the ability to become ssh access if she want - unless she have first a console login.
For reasons of security maybe not the best solution, but i am thinking an after base-installation scenario. In many cases i would work straightaway with ssh after installation. In Nethserver the root has no ability to ssh with password after installation (as i remember) and therefore he cannot prepare a ssh-key login. If wheel and posix admin also has no shh at this time, it end out of here.
In my opinion it is better giving ssh for “wheelers” than loosing the new posibillities with the new ssh scenario and his usefull functions (e.g. user access for server-manager).
I am open minded for changes it is sure but I have the feelings here you want to make NethServer workable with your way and unfortunately we need to make NethServer workable for everybody, so we have sometimes to cut the apple in two pieces, or keep the apple in the kitchen.
Can we summarise the typical Nethserver ssh scenario? For what is ssh for users and admins?
In your scenario (as i unterstand this), Domains Admins have access to server-manager, ssh, sftp, ssh tunneling (again the whole maintenance stuff)
Account provider have access to special server-manager functions (new), maybe for sftp, in rare cases for ssh tunneling
In my Cases:
Posix Admins (more knowledge / more privileges): having acess to server-manager, ssh, sftp, ssh tunneling (the whole maintenance stuff)
In my Opinion:
Domain Admins should not have generally access to ssh (an also not for server-manager), because this account is required for AD joining - and ONLY for similar actions.
Account credentials with such a high access level (sudo and ssh) should better never ever leave secure systems under your own control (like your personal devices for maintenance).
But ever if you join a client-device to an AD you have to use credentials of an domain admin on a device thats not fully under your control. If the credential was “fished” at this moment (or somthing later if your cannot avoid to use), you have a big problem - the “fisher” has now full access to ANY active directory joined devices (bad enough) but also on your Nethserver.
Therefore maybe domain admin should not have ssh access generally (or maybe only per ssh-key).
But we need an alternate for that (not only but also for rescue cases)
In my (realy unusual?) usage scenario the POSIX admins are for server-manager and for ssh. So i can control that this credentials never leave my mantenace devices. It is simple not necessary to use this credentials on a “forein” device (because the are useless in most cases).
Maybe a “middle” way would be not to allow ssh for doman admins (or with ssh-key only) and instead using separate (special) user accounts with ssh access and the possibility for sudoing. So external access is possible and also sudoing for maintenance.
But have this user “full” access for server-manager if not in domain-admin group?
And (last and again) what about rescue cases when the account provider is bad?
I fully agreed but meanwhile I think it could be an inconsistency in UI and Nethserver concept because you can’t add a local user to wheel group in UI yet and local users are not mentioned in Nethserver docs.
Maybe we can add a db prop that’s set to disabled by default to allow wheel group to be compatible to CentOS and to not suddenly allow SSH for accidentally created and forgot users at install.
Yeah, anaconda is misleading (see my post) but I found no way to customize it. Maybe point it out more in the documentation.
I think with a custom template everybody could be satisfied (add wheel group, allow posix group/user, disallow domain admins).
This way we have nearly no effort and follow the Nethserver concept of forcing account provider users and provide the possibility to create a custom template for wanted “exceptions” easily.
This could be set more times and tough keeps every setting so it’s already easy to customize.
We could split /etc/e-smith/templates/etc/ssh/sshd_config/70Restricted2Sftp to make it easy to set custom Match Group directives.
It’s not possible at posix level. You only can enable users full access with domain groups by adding them to domain admins or use role delegation.
Domain infos are cached:
You could create a domain user “mysambaadmin” and add this user to administrators group with samba-tool. This way you get a samba admin for clients to join the domain but no domain admin so no login to UI possible.
Thank you for you detailed informations. i understand, that the current Nethserver concept is to use an account provider and therefore not to provide a enlarged usage scenario of posix users/groups. I understand this decision, but i regret that in details.
I was wondering since my first Nethserver installation that the server-manager has not even the option to manage the while installation installed basic accounts. For a non-terminal-competent user this accounts are unusable and therefore forgotten and lost in fact - and this can be a serious security risk. In server-manager there is no option to remove/disable or give new passwords for such accounts.
By the way, there is also no option to change the “root” password in server-manager. In some cases the “Nethesis,1234” password could be deferred and less experienced user have no option to change it.
What if Nethserver is used for Services without an account provider? There are so many options / scenarios for using Nethserver without own or binding to an external account provider and most of them can be completely installed and managed within server-manager. But within server-manager there is no (non terminal) option to change the “maintenace” account (root) password or to create a second maintenace account (other posix admins with right for server-manager). Or i am blind.
In my opinion, there should maybe at least an option to change the root password from server-manager - like usual in any other webconfigs for routers/firewalls or others. Maybe on an other place as the user/groups panel. (on this place, there could be a posix account managing option without confusing the Nethserver like account managing)
In compatibility to CentOS the posix-user existence has to be considered anyway.
Even if you have no need for an Account Provider, and maybe not even a need for a user besides root:
What’s stopping you from installing a simple LDAP “Account Provider”?
It’s there, and configured, but doesn’t block or stop you.
In german we also say “Frisst mir kein heu weg!”
BTW: The NethServer root does NOT use “Nethesis,1234” as a password, only the default Nextcloud admin uses that!
It’s a bit akin like on a current Windows 10 64 Bit machine and thinking: I’m on a 64 Bit OS and Box, I have no need for C:\Windows\System32, there’s a folder C:\Windows\System64 replacing that… So after removing the System32 folder, you “might” have major problems rebooting…
You could also try removing /etc/group and /etc/passwd and /etc/shadow on any linux / unix box, thinking I don’t need local users… You WILL have problems.
Same thing in NethServer, it’s there for a reason…
You can change the root password both from the new and old Server Manager: http://docs.nethserver.org/en/v7/access.html#change-the-current-password
On the old one, you are even asked to do it during the first configuration wizard.
In the new one, you have a yellow warning which ask you to change the password.
For the new Server Manager you can change the password using System → Settings
We have thousands of such installations, usually firewalls.
If you do not need users, just use root for anything.
If you need users, you can simply install the LDAP account provider and manage everything from the UI.
I can’t wait to see your PR!