View previous topic :: View next topic |
Author |
Message |
sdauth Guru
Joined: 19 Sep 2018 Posts: 568 Location: Ásgarðr
|
Posted: Thu Apr 07, 2022 6:48 pm Post subject: SSH only allow specific sshfs mount and nothing else |
|
|
Hi,
How to only allow a specific (root) sshfs mountpoint and nothing else ?
I added the key for the server (a VM) in /root/.ssh/authorized_keys with these options to prevent allocating a PTY :
Code: | no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 blablabla root@server |
Then logged in my server, I can mount the desired folder from my desktop without issue :
Code: | sshfs root@desktop:/var/cache/test /mnt/test |
or since I added an entry to /etc/fstab :
sshfs#root@desktop:/var/cache/test /mnt/test fuse noauto,_netdev 0 0
but is it possible to go one step further and only allow this specific mount point to be mounted ?
I know about the command="" option but what do I need enter ?
Example, if I enter "date", like that :
Code: |
command="date",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-ed25519 blablabla root@server |
then
correctly returns the date and close after that.
So I guess it should be possible to only allow sshfs ? Thanks. |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3131
|
Posted: Thu Apr 07, 2022 10:16 pm Post subject: |
|
|
AFAIR sshfs is a wrapper around sftp, so force-command internal-sftp + chroot jail for ssh user should do the trick.
Caveat: you don't want to ban yourself from using root account for managing the system, which means you better create a dedicated account for sharing files*.
Mount --bind -o uid=<sftp_user> should take care of both, access path and and file permissions. Not sure what permissions will be required by newly created files though. Alternatively, gid=<sftp_group> may be a better option. There is also mode= which may or may not come in handy.
Basically, create a user which can see the files you want accessible via sshfs inside his home directory, and then prevent the ssh session from escaping that directory.
*unless you know a way to chroot jail based on matching the key rather than matching parameters of the account itself. Command can be forced on the account (in sshd config) or on the public key (in authorized_keys), but I've never tried forcing chroot jail based on the key. |
|
Back to top |
|
|
sdauth Guru
Joined: 19 Sep 2018 Posts: 568 Location: Ásgarðr
|
Posted: Fri Apr 08, 2022 9:14 am Post subject: |
|
|
Thanks szatox, I never used chroot jail so I will need to read a bit more first. I will update this thread later |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21595
|
Posted: Fri Apr 08, 2022 11:52 am Post subject: |
|
|
Is sshfs the right solution here? Usually, sshfs is used when you do not control the remote end enough to enable NFS / CIFS. Since you have root on the target, you might be better off using NFS and relying on it to restrict what directories are shared. |
|
Back to top |
|
|
sdauth Guru
Joined: 19 Sep 2018 Posts: 568 Location: Ásgarðr
|
Posted: Fri Apr 08, 2022 1:44 pm Post subject: |
|
|
@Hu, well I actually did that an hour ago..
on the desktop :
/etc/fstab
Code: | /var/cache/test /mnt/nfs/share/test none bind 0 0 |
/etc/exports
Code: | /mnt/nfs/share 192.168.1.0/24(rw,async,no_subtree_check,crossmnt,no_root_squash,fsid=root) |
I was missing "no_root_squash,fsid=root" initially so I was wondering why I wasn't able to write on the client.. (permission denied)
And on the client (the vm)
/etc/fstab
Code: | 192.168.1.10:/test /var/cache/test nfs rw,nosuid,nodev,auto,nouser,noexec,async,soft,rsize=32768,wsize=32768,timeo=500,retrans=5 0 0 |
Works 100% for this particular use case.
I will still have a look at chroot jail but NFS seems better answer here. (I was lazy to recompile my kernel to add nfs support to be honest so since ssh service was already set up, I thought it would have been easier to just use that..) |
|
Back to top |
|
|
sdauth Guru
Joined: 19 Sep 2018 Posts: 568 Location: Ásgarðr
|
Posted: Sat Apr 09, 2022 8:47 am Post subject: |
|
|
Following szatox suggestion with chroot jail, I was wondering if only adding internal-sftp to command would to the job. It does.
On the desktop :
/root/.ssh/authorized_keys
Code: | command="internal-sftp",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc ssh-ed25519 blablabla root@server |
And then on the server :
Code: | ssh root@desktop
PTY allocation request failed on channel 0
This service allows sftp connections only.
Connection to desktop closed. |
Code: | sshfs root@desktop:/mnt/test /mnt/test |
mounts fine.
Of course, I could also mount anything under / like that... No restriction at all, or maybe there is an easier solution, without chroot involved to only allow a set of hardcoded path to be mounted ? I know it is the purpose of chroot jail in the first place but it is a bit confusing. I don't want to add another user, group etc..
NFS on the other hand is better I think here as you define in /etc/exports what is allowed to be accessed precisely.
I will stick to NFS meanwhile I think |
|
Back to top |
|
|
szatox Advocate
Joined: 27 Aug 2013 Posts: 3131
|
Posted: Sat Apr 09, 2022 4:13 pm Post subject: |
|
|
Well, if you run it in an isolated network, NFS is fine. Sometimes people do share files over the internet though. And then you find out that NFS lacks some important security features.
Sshfs is one low-performance way to circumvent it.
Bridging the gap with an encrypted overlay network (e.g. wireguard) is another.
I actually quite like the latter, as it's a generic solution usable pretty much for anything on my end. Once we get to the end user connection, application-specific ssl support starts to shine.
And yes, chroot for ssh sessions is confusing. And ugly on top of that. But it does have its uses, so well, whatever... |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|