Closed mhindery closed 9 years ago
When enabled, the system's default SFTP subsystem is used, thus overriding lshell (and its restrictions). I had a plan to code a restricted SFTP subsystem, but eventually crossed it off my todo list.
I will add a warning to the man/config files for the user to be aware of this.
But disabling doesn't seem to work either. I still have sftp access.
I am unable to reproduce this.
With sftp set to 1:
mazzika:~$ sftp machi@localhost
Connected to localhost.
sftp> ^D
With sftp set to 0:
mazzika:~$ sftp machi@localhost
Connection closed
It's an issue that appears when the chroot configuration of sshd in Ubuntu is used. I created a user 'testuser' configured to not allow sftp, and added the lshell config:
root@surfin:/home/mhindery# adduser testuser
Adding user `testuser' ...
Adding new group `testuser' (1002) ...
Adding new user `testuser' (1002) with group `testuser' ...
/* cut lines with user info */
root@surfin:/home/mhindery# usermod -aG lshell testuser
root@surfin:/home/mhindery# chsh -s /usr/bin/lshell testuser
root@surfin:/home/mhindery# id testuser
uid=1002(testuser) gid=1002(testuser) groups=1002(testuser),120(lshell)
The lshell conf has as only option sftp : 0 (no other groups or users configured). For now, everything works correctly on out of the box Ubuntu. However, when enabling chroot functionality for a group, the user gets unrestricted access over sftp.
chroot config is located at the bottom of : /etc/ssh/sshd_config
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
# Set this to 'yes' to enable PAM authentication, account processing,
/* cut some comments out for brevity*/
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
Match Group sftp
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
Notice how the testuser is not member of sftp group, but still circumvents something somewhere.
@ghantoos Any thoughts?
Thanks for all the details!
The check is done here: https://github.com/ghantoos/lshell/blob/master/lshell/checkconfig.py#L691
When a user connects, lshell catches the command line that is executed through ssh. If "sftp-server" is caught, then it reacts depending on the configuration file.
However, in your case, it seems that the internal sftp is used, and so no command is appearing to be executed, thus not being caught by lshell on the command-line.
We need to look into this, and see if it is possible to restrict sftp when using chroot or not.
I'll keep you posted, unless you find a way to correct this behavior. ;)
I have just done some tests. It appears that the user's shell (lshell in our case) is not called at all when the internal-sftp subsystem is used. This makes it impossible to process the connection via lshell.
I will keep this open, and add a notice in the documentation.
Tell me if you think there is more to it.
Well, this looks like non-fixeable indeed. It make lshell unusable for us, too bad, because other than this issue, it's really a nice tool! And indeed best to notice users of this issue, quite a big loophole otherwise :)
I'm sorry to see that lshell won't be working out for you. Thanks for taking all this time to report these issues! :)
When enabling the sftp option, a user can browse the entire system. He can list and download directories/files in paths that are not specified as allowed.
Edit: In fact, setting sftp to 0 doesn't work at all, I still have sftp acces.