SSH+SFTP restricted authorizations

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 root must 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

  1. legacy
  2. admins only
  3. 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! :wink:

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

  1. Design and add the SFTP chroot feature
  2. Show a checkbox in the UI, so it’s easy to upgrade to the new behavior. Add documentation to the admin’s manual
  3. Switch the default prop value to enabled in 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)

:warning: 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 :-?

:beers: I need a Belgian beer and @giacomo, @edoardo_spadoni to answer this question

I need a new angel to watch me at bruxels, last year it was @Sebastian, the night was fun, but it was hard sunday morning

2 Likes

I’d say the Settings page, which is like a trash bin :smiley:

1 Like

Yes, it could be easy to find and code it, even if it is not there I could think to find it. From my point of view, the user/group menu could be a better place

Either the modal of the edit the account provider or maybe a checkbox directly in the page menu

Why not in SSH?
Or SFTP do not change port when SSH port is changed?

In fact we introduced a new prop under sssd to force the shell of users to /bin/bash, like this any users could login to cockpit/ssh. For security reasons we also introduce a ssh and cockpit AllowsGroups and restrict who is able to connect

so the question now is where to expose the sssd prop checkbox

I agree. The checkbox just need to be there and checked one time, to upgrade to the new system behavior. New ns 7.8 installations will receive it as default setting.

Meanwhile your latest enhancements were released :wink:

1 Like

I’ve installed it on three production servers and it’s perfect!

Great job :+1: @stephdl

4 Likes

A post was split to a new topic: SFTP chroot howto