A currently maintained fork of SSHFS • Hacker News Board

Re: A currently maintained fork of SSHFS

#141

Post by effie » Fri, Sep 08, 2023, 1:06 AM UTC

Is there a more security-oriented alternative to SSHFS, where the connecting client won't be given shell access on the server? I just want to share a directory from server to an untrusted VM over network, and have VM mount it, not give the VM shell access to the server.

FTP is close to such a thing, but it is somewhat archaic, slow and not sure about its security.

Re: A currently maintained fork of SSHFS

#142

Post by quoiquoi » Fri, Sep 08, 2023, 3:09 AM UTC

effie wrote: post #141

Is there a more security-oriented alternative to SSHFS, where the connecting client won't be given shell access on the server? I just want to share a directory from server to an untrusted VM over network, and have VM mount it, not give the VM shell access to the server. FTP is close to such a thing, but it is somewhat archaic, slow and not sure about its security.

If the user account is only supposed to have file transfer capabilities/no shell access, add it a to a specific group e.g. `sftponly`, and only allow this group to use the `internal-sftp` command in `/etc/ssh/sshd_config`

    Match Group sftponly
    ForceCommand internal-sftp -l INFO -f LOCAL6
    AllowTcpForwarding no
    AllowAgentForwarding no
    GatewayPorts no
    X11Forwarding no

Re: A currently maintained fork of SSHFS

#143

Post by jakobson14 » Fri, Sep 08, 2023, 11:27 PM UTC

kpw94 wrote: post #104

Zambyte wrote: post #62

Earlier quoted context omitted.

My favorite thing about using TRAMP is being able to cd to a directory on a remote system, and then cp a file either from my working directory to my local machine (or another remote!), or from my local machine to the current working directory. Before I started using TRAMP, my flow for this was: SSH to a remote system, locate where I want to copy a file to with cd + ls, kill my SSH session, and then scp or rsync the f…

> kill my SSH session, and then scp or rsync the file over, and then usually SSH back into the system. Naive question: why the need to kill the ssh session? Can't you just open another terminal window or tab (or tmux/screen tab if that's part of your workflow)

Or just scp from the server, inside the same SSH session. scp works both ways.

Re: A currently maintained fork of SSHFS

#144

Post by effie » Sat, Sep 09, 2023, 4:35 AM UTC

quoiquoi wrote: post #142

effie wrote: post #141

Is there a more security-oriented alternative to SSHFS, where the connecting client won't be given shell access on the server? I just want to share a directory from server to an untrusted VM over network, and have VM mount it, not give the VM shell access to the server. FTP is close to such a thing, but it is somewhat archaic, slow and not sure about its security.

If the user account is only supposed to have file transfer capabilities/no shell access, add it a to a specific group e.g. `sftponly`, and only allow this group to use the `internal-sftp` command in `/etc/ssh/sshd_config` Match Group sftponly ForceCommand internal-sftp -l INFO -f LOCAL6 AllowTcpForwarding no AllowAgentForwarding no GatewayPorts no X11Forwarding no

Thank you, this seems to prevent client getting shell on the server, while allowing it to make SSHFS mounts. I've put /usr/sbin/nologin into client's row in /etc/passwd on the server as well (/dev/null would break everything including SSHFS).

Is there some way to specify that nothing except internal-sftp is allowed, as opposed to setting each option explicitly to "no"? The latter way seems error-prone, one is bound to miss some obscure option there.

And I wonder why do you suggest using the LOCAL6 log facility? In sftp-server, the default is AUTH...