SSH+SFTP restricted authorizations

Feature
1

To continue the topic Sftp chroot is needed

I would like to open a new thread and list what we would like to achieve with sftp, it seems that chroot, access were on the table, so I listen you

@dev_team @Dixan83 @flatspin

4 Likes
2

IIUC, there are two main goals

  • separate SSH and SFTP access. If necessary users that can do SSH can be granted SFTP too, but not the other way round
  • select users or (better IMO) groups that are granted SFTP access

Developer’s wish: get rid of /usr/libexec/openssh/sftp-server as user’s shell. I’d like either /bin/bash or /bin/false

3 Likes
3

Other feature: as many required a secure FTP alternative for virtual hosts too, we could study how to integrate the filesystem permissions of virtual hosts web root directory with SFTP.

2 Likes
4

That’s what I wnated to say ind the old topic.

5

If anything, I’d think it should be the other way 'round. SSH access gives the user the ability to do a lot of stuff on the system; SFTP just lets them transfer files. It seems like there would be more reason to give (SFTP but not SSH) to a user than (SSH but not SFTP).

2 Likes
6

Hi Team!
1- Jail ssh service to the user home directory.
2- A way to disable the sftp likle ssh service.
3- Define by default the /bin/rbash shell for all user. rbash is great to restrict certains commands.
Jailing the user to his own directory solves the cross pass issue to the top directories.
I made this in the past but all at hands. I dont know how make the magic and integrate this to the cockpit gui or the old gui.
Regards!

7

Absolutely not.

Agree this would be useful.

Why? What’s the point of giving ssh access if it’s going to be so limited?

8

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 :slight_smile:

9

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.

10

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.

11

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
12

A post was merged into an existing topic: 2FA or two-factor authentication with cockpit

13

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.

14

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.

15

what we could break for current users ?

16

We shouldn’t touch them. The change has to be effective for new users only.

17

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

18

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

19

…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
20

It sounds like a great plan! :wink:

3 Likes