Locking down a users access to just sftp, and just one path?

TrueNAS General
1

Hi,

I’m interested in using an application that wants a ssh key to push files over SFTP to my TrueNAS Scale box. I’d like to do as much as I can on the NAS to constrain the account/keypair to only be able to upload files, and only to the directory specified.

Looking over existing forum posts, I see some descriptions of modifying sshd_config to lock accounts to only their home directory, and that this requires root/wheel owning all of the directories in the path. I would like a different solution, if it exists.

I’d appreciate any advice!

2

Did you set the shell for this “restricted account” to “scponly”? (This can be done in the user’s config page.)

I believe this will give the user access to SSH/SFTP, pushing keys, uploading and downloading files, transferring over Rsync, etc, but the user will not be allowed to login to a terminal session.

1 Like
3

Thanks for the advice, but scponly doesn’t appear to be an option.

image

4

@kris @Captain_Morgan @awalkerix

Was “scponly” removed from SCALE?

I have it (and use it) on TrueNAS Core. (For almost the same reasons that the OP is suggesting, although my use-case is slightly different.)

5

scponly was removed from Debian 12 years ago. Don’t know why, maybe security? We could look at enabling alternatives, but maybe a good feature request to gauge how many others miss that option?

6

I may be wrong but I have a feeling that ‘no login’ still allows the user to scp just no shell.

7

slowpoke-winnie

This is my self portrait. Thanks for embarrassing me in front of all these people. :sweat_smile:

I don’t believe so? I think nologin will not even allow scp, SFTP transfers, Rsync over SSH, and other transfers over SSH. It will simply reject any commands from the user.

I remember I had to explicitly use “scponly” to do what the OP is suggesting, for my own use-case. (Transfering, without the need to allow shell access.)

8

I gave it a shot. Created a new user with password auth disabled, shell set to nologin, with home directory, and with an authorized key. sftp didn’t seem to work.

image

9

That’s why “scponly” exists. It fills that purpose of “allow transfers, but deny shell login access”.

Apparently, it’s still available for some Linux distros (such as Arch Linux and Fedora), but not others (such as Debian and openSUSE).

Not sure what the alternative for “scponly” is for Debian.

10

Yeah sorry I was probably dreaming :sleeping:

1 Like
11

Nope, it was my mistake:

image

Fixed that, and now I can sftp into the machine with nologin set:

image

But the issue is still that the user has access to the whole filesystem:

image

12

Isn’t this what chroot is used for?

Here’s an example related to TrueNAS, albeit not SCALE.

1 Like
13

Thanks for the suggestion. That looks like it could work, but I’d like to avoid the root:wheel path requirements, and locking all other sftp users into their home directories.

14

So it seems like you can achieve this with ‘nologin’ selected however you would need to add the following to the Auxiliary Parameters in the SSH service.

Match User username
    ForceCommand internal-sftp
2 Likes
15

Thanks! I don’t know how I missed that, but I thought the chroot directory applied to all users logging in. SFTP chroot works great!

1 Like
16

Before the update to 25.04, the design of locking users in the form of an added code worked fine.

Match group work_users
ChrootDirectory %h
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no

Match group home_users
ChrootDirectory %h
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no

After updating to 25.04 with such additional parameters, SCALE refuses to start the SSH service and returns an error.

[EFAULT] Apr 18 05:55:19 systemd[1]: Starting ssh.service - OpenBSD Secure Shell server… Apr 18 05:55:19 sshd[4447]: /etc/ssh/sshd_config line 30: Directive ‘UsePAM’ is not allowed within a Match block Apr 18 05:55:19 systemd[1]: ssh.service: Control process exited, code=exited, status=255/EXCEPTION Apr 18 05:55:19 systemd[1]: ssh.service: Failed with result ‘exit-code’. Apr 18 05:55:19 systemd[1]: Failed to start ssh.service - OpenBSD Secure Shell server. Apr 18 05:55:19 systemd[1]: ssh.service: Scheduled restart job, restart counter is at 1. Apr 18 05:55:19 systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server. Apr 18 05:55:19 systemd[1]: Starting ssh.service - OpenBSD Secure Shell server…

If you comment out the Match group, the SSH service will start

What has changed in 25.04 ?
How do I lock users in my home directory now?
Why is the Match group now considered an error?