Absolutely not.
Agree this would be useful.
Why? What’s the point of giving ssh access if it’s going to be so limited?
As the ssh service is configured now, anyone can access to the main directory and read critical files. the point to keep the standar user inside of a jail in his home directory is to prevent a read-write escalation in the server.
I see your point but the point is hardening the ssh server. Define the commands to be allowed depending of the user´s group will be a great feature to take in mind. Until now, we can define a simple rule to allow or denny the ssh access and works fine, but we can go a little more far 
Yes, they can read them. Why is this a problem?
…which most users don’t have access to anyway, and normal users wouldn’t need at all, except that (1) for some inexplicable reason, access to the Cockpit server manager is tied to SSH access, and (2) through the server manager is the only officially-supported way to change a user’s password.
Ok, I have configured the 2fa from google to get access into my ssh services. Is very simple and easy to activate modifing at hand 2 files, but I don know how to make the magic and enable it in cockpit, perhap dev can make the magic for all of us :). If 2fa option is allowed then we can ignore the restriction and the jail suggestion. Only the sftp enable/disable option is needed. 2fa will hardening the ssh server.
this is another request I have, it is cover at 2FA or two-factor authentication with cockpit and Two factors of authentication in cockpit by stephdl · Pull Request #191 · NethServer/nethserver-cockpit · GitHub
1 Like
Other than that both of these relate to some vague idea of “hardening”, what do they have to do with each other? One deals with user authentication; the other with the user’s capabilities once authenticated. And if you want to more securely authenticate your SSH users, disabling passwords and requiring public keys is already available, at least as secure as 2fa, and requires no additional software on the server.
It´s was a solution until the sftp-ssh issue is solved. Today, the sftp service grants access to the top directory. In my case, it is a hight issue and I have to minimize that without disabling the service.
Jail the user into his own home directory will hardening the ssh service. Then, the method used to validate the authentication using public key, 2fa, carrier pigeons, is an extra layer of security.
The level of security defined by default in nethserver works for all of us, but there are some cases that extra configuration in certain services is needed.
what we could break for current users ?
We shouldn’t touch them. The change has to be effective for new users only.
proposal, my wish list to santa claus
inside the ssh cockpit page, make two dropdowns multiselect
a list of group to delegate the access to ssh (root is default)
AllowGroups root famille@nethservertest.org
a list of group to use sftp
Subsystem sftp internal-sftp -u 0077
Match Group famille@nethservertest.org
# ChrootDirectory /home
X11Forwarding no
AllowTcpForwarding no
eventually a chroot for sftp, but this lead some cons
- we can chroot only /home, not /home/stephane, else
rootmust be the owner of the home folder…it is not possible - when chroot, the user cannot login to ssh
I think we could switch to /bin/false for new users, we could use sftp, and the ssh instance is stopped, but the MOTD is displayed and I do not like it, so I would like to propose to find a solution to not display the MOTD
TODO: block groups not allowed to use sftp
Back on it
hum it seems when you are allowed to use ssh by default you are allowed to use sftp, it makes sense, you are delegated to the higher permissions, so also for sftp
If you are delegated to ssh, you can use sftp
If you are delegated to ssh , we can force you to use only sftp, eventually with a chroot
I am not sure we have many options here
…so my plan is
- a list of groups that can do SSH+SFTP
- a list of groups that can do just SFTP (with optional chroot jail)
- …if a user is not member of the listed groups, no access is given
probably a special “everyone” wildcard can be implemented
Possible implementation is the Match Group directive as documented in sshd_config(5) manpage.
Other relevant directives:
ChrootDirectory
ForceCommand
AllowUsers
There could be three main policies
- legacy
- admins only
- custom
The legacy (1) policy is what we have now, selected by default on existing systems.
Admins only (2) grants ssh+sftp access to domain admins (or whatever admins/group prop points to), and denies access to all the others. This could be the future default one.
The custom (3) policy can be fine tuned with the prop group lists.
3 Likes
It sounds like a great plan! 
3 Likes
we have something ready to be tested… please jump in it
2 Likes
It seems the SSH+SFTP and Cockpit access is working well. We can release this bundle with the new ShellOverrideStatus prop at disabled, so that existing systems are not affected. In this period of hidden “beta” we can complete the chroot part.
Next steps could be
- Design and add the SFTP chroot feature
- Show a checkbox in the UI, so it’s easy to upgrade to the new behavior. Add documentation to the admin’s manual
- Switch the default prop value to
enabledin NS 7.8
What do you think?
2 Likes
For what I tested it is not so simple, it was not really a goal, so I did not loose much time on it, but in short if you chroot the user to sftp, then the ssh is broken because /bin/bash is no more in the path ( failed to run command ‘/bin/bash’: No such file or directory ). You have some tricks to make it available, but it is a matter to copy libraries to /var/lib/nethserver/home.
To be honest I am not a big fan
agreed
1 Like
A first bundle of the new features was released! See Group-based access restriction for Cockpit and SSH · Issue #6029 · NethServer/dev · GitHub
With the upgraded packages it is possible to preview the new system behavior with the following commands (see README)
do not run in production!
config setprop sssd ShellOverrideStatus enabled
signal-event nethserver-sssd-save
Next step is:
2 Likes
where is the best place for this checkbox :-?
I need a Belgian beer and