Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Need some help chrooting SFTP-only user access
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Need some help chrooting SFTP-only user access

zserozsero Member
edited September 2013 in Help

I need to give access to a folder to a user who needs to work with Wordpress sites over SFTP.

What I would like to do is to make sure that:

  1. He cannot run SSH, just SFTP

  2. He cannot see anything from the filesystem other than /home/userdir

From what I read this is exactly chrooting, however I have a few problems setting it up. I am on Debian 6 with Dropbear as SSH daemon.

A few questions:

\1. Originally my sftp subsystem was set up like this in /etc/ssh/sshd_config:

Subsystem sftp /usr/lib/openssh/sftp-server -u 0007

now in most tutorials it says that I have to change it to:

Subsystem sftp internal-sftp

Is this correct? Doesn't internal-sftp mean dropbear in my case? Should I change to openssh for chrooted SFTP accounts?

\2. Some tutorials ask to disable the user's shell with usermod -s /bin/false someuser. However when I do this, it disables SFTP as well. Is this normal?

\3. Finally tutorials usually note the following lines in the sshd_conf for the actual chrooting, or something similar:

Match group sftponly
         ChrootDirectory /home/%u
         X11Forwarding no
         AllowTcpForwarding no
         ForceCommand internal-sftp

However this had no effect for me. Is this because I'm using Dropbear?

Can someone tell me which are the proper steps to restrict to SFTP-only + home directory only access on Debian 6?

Comments

  • For SSH :

    1. Keep
    Subsystem sftp /usr/lib/openssh/sftp-server
    

    Like you thought.

    1. The match block basically like you put :
    Match Group sftp-only
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no
    

    3.

    usermod -a -G user sftp-only
    
    chown :sftp-only /home/user
    
  • I have yet to find a way of properly chrooting SFTP with Dropbear so I'm starting to believe it is not possible at the moment.

    ad 2) Yes, setting the user's shell to /bin/false disables SFTP as well. You should use (and trust) the ForceCommand directive which will disallow any interactive SSH session. Or, to add an extra layer of security, you can use something like sftpsh (adjust SFTP_BINARY path, compile, add to /etc/shells and set as the user's shell).

  • @MiB said:
    I have yet to find a way of properly chrooting SFTP with Dropbear so I'm starting to believe it is not possible at the moment.

    ad 2) Yes, setting the user's shell to /bin/false disables SFTP as well. You should use (and trust) the ForceCommand directive which will disallow any interactive SSH session. Or, to add an extra layer of security, you can use something like sftpsh (adjust SFTP_BINARY path, compile, add to /etc/shells and set as the user's shell).

    Setting the shell to

    /usr/lib/openssh/sftp-server

    works fine too

    and you can probably assign /dev/nologin too as you're forcing sftp anyway

  • zserozsero Member
    edited September 2013

    Thanks a lot for the tips.

    1. With Dropbear many of the variables had no effect, so I purged dropbear, purged openssh-server and reinstalled openssh-server. Now at least all commands have a clear effect.

    2. I like the usermod -a -G sftp testuser kind of adding users to a sftp-only group. This concept is clear to me.

    3. With the help from here, and also from the git version of minstall, I made this config file:

    AllowUsers root test
    PermitRootLogin yes
    UsePAM yes
    
    ChallengeResponseAuthentication no
    Port xxxx
    Protocol 2
    Subsystem sftp /usr/lib/openssh/sftp-server -u 0007
    
    Match Group sftp
        AllowTcpForwarding no
        ChrootDirectory /home/%u
        ForceCommand internal-sftp
    

    However, the problem is that this was I cannot log in even with sftp.

    Here is what I get with SFTP:

    Write failed: Broken pipe
    Couldn't read packet: Connection reset by peer
    

    And what I get with SSH:

    : command not found
    

    Why does it happen? Am I missing some packages?

  • Change the subsystem sftp to:
    Subsystem sftp internal-sftp

    You can see the manual here: www.openbsd.org/cgi-bin/man.cgi?query=sshd_config

    The sections of interest are ChrootDirectory and ForceCommand.

  • I changed it to Subsystem sftp internal-sftp, but there is no difference.

    I just simply get Write failed: Broken pipe

    This is my config now:

    AllowUsers root test
    PermitRootLogin yes
    UsePAM yes
    
    ChallengeResponseAuthentication no
    Port xxxxx
    Protocol 2
    Subsystem sftp internal-sftp
    
    Match Group sftp
        AllowTcpForwarding no
        ChrootDirectory /sftp
        ForceCommand internal-sftp
    

    And /sftp is set up by chown root:sftp /sftp

    What else can be the problem?

  • As @Frost mentioned, you don't need to alter the Subsystem line.

    Not sure why it it's not working for you.

    1. chmod 755 /sftp

    If that fails...

    1. Try changing the sftp group to a different name, to avoid naming conflicts.
  • I changed the group, as well as Subsystem but still no luck.

    Now I have sftpusers, chown root:sftpusers /sftp and chmod 755 /sftp and still get this connection closed.

    Also in /var/log/auth.log everything seems fine.

  • Strange.

    I don't know if this is actually true, but apparently password authentication needs to be enabled for sftp to work ?

    Also, compare between cli client and the gui client gftp set to SSH2, to be double sure.

    Otherwise, clueless.

  • It must be something within the match group, since with root I can easily SFTP in. What do you mean "password authentication needs to be enabled"? I am trying to log in using password, not SSH keys. Is there anything with UsePAM or ChallengeResponseAuthentication which might be bad?

  • If you comment out the ChrootDirectory line can you get in?

  • The same,

    Sep 17 14:08:48 ssdkvm sshd[15341]: Accepted password for test from ::1 port 36603 ssh2
    Sep 17 14:08:48 ssdkvm sshd[15341]: pam_unix(sshd:session): session opened for user test by (uid=0)
    Sep 17 14:08:48 ssdkvm sshd[15343]: subsystem request for sftp
    Sep 17 14:08:48 ssdkvm sshd[15343]: Received disconnect from ::1: 11: disconnected by user
    Sep 17 14:08:48 ssdkvm sshd[15341]: pam_unix(sshd:session): session closed for user test
    
  • As ChrootDirectory is not the problem, I would suggest adding a new user and testing at each step, to see where things go wrong. If a non-root user can't get in at all, you may want to revert to the default configuration for OpenSSH.

    You can enabled sshd debugging by running the daemon with -d on a new port and connecting to that instead. For example /usr/sbin/sshd -d -p 2233

  • I am on Debian 6 with Dropbear as SSH daemon.

    that's the problem. I use that config with wordpress too, but you need to use proper sshd first.

    about >He cannot see anything from the filesystem other than /home/userdir

    don't forget to set your php security with
    [HOST=www.yourusersite.com]
    open_basedir="/home/your-user/www.yourusersite.com"
    and verify that /home/your-user/ is owned by root and chmod 755 and don't forget to set the sticky bit, if you still want wordpress editor to be able to modify template files etc.

    so basically you need to:

    vi /etc/ssh/sshd_config
    
    Match Group sftponly
        ChrootDirectory %h
        AllowTCPForwarding no
        X11Forwarding no
        ForceCommand internal-sftp
        
    mkdir /home/your-user
    useradd --home /home/your-user --groups sftponly,www-data --shell /bin/false your-user
    mkdir /home/your-user/http/
    passwd your-user
    chown your-user:www-data /home/your-user/http/
    chmod 750 /home/your-user/http/  
    chmod g+s /home/your-user/http/
  • What about rssh?

  • zserozsero Member
    edited September 2013

    @colm, thanks a lot for the debug line. Here is what's been logged after connection. I have no idea what is wrong, everything seems OK to me!

    debug1: Server will not fork when running in debugging mode.
    debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
    debug1: inetd sockets after dupping: 3, 3
    Connection from xxxx port 27730
    debug1: Client protocol version 2.0; client software version WinSCP_release_5.1.4
    debug1: no match: WinSCP_release_5.1.4
    debug1: Enabling compatibility mode for protocol 2.0
    debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze3
    debug1: permanently_set_uid: 101/65534
    debug1: list_hostkey_types: ssh-rsa,ssh-dss
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: client->server aes256-ctr hmac-sha1 none
    debug1: kex: server->client aes256-ctr hmac-sha1 none
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
    debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
    debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: SSH2_MSG_NEWKEYS received
    debug1: KEX done
    debug1: userauth-request for user test service ssh-connection method none
    debug1: attempt 0 failures 0
    debug1: user test matched group list sftpusers at line 13
    Failed none for test from xxxx port 27730 ssh2
    debug1: userauth-request for user test service ssh-connection method keyboard-interactive
    debug1: attempt 1 failures 0
    debug1: keyboard-interactive devs
    debug1: auth2_challenge: user=test devs=
    debug1: kbdint_alloc: devices ''
    debug1: userauth-request for user test service ssh-connection method password
    debug1: attempt 2 failures 1
    Accepted password for test from xxxx port 27730 ssh2
    debug1: monitor_child_preauth: test has been authenticated by privileged process
    User child is on pid 11216
    debug1: SELinux support disabled
    debug1: permanently_set_uid: 1011/1012
    debug1: Entering interactive session for SSH2.
    debug1: server_init_dispatch_20
    debug1: server_input_channel_open: ctype session rchan 256 win 2147483647 max 16384
    debug1: input_session_request
    debug1: channel 0: new [server-session]
    debug1: session_new: session 0
    debug1: session_open: channel 0
    debug1: session_open: session 0: link with channel 0
    debug1: server_input_channel_open: confirm session
    debug1: server_input_channel_req: channel 0 request [email protected] reply 0
    debug1: session_by_channel: session 0 channel 0
    debug1: session_input_channel_req: session 0 req [email protected]
    debug1: server_input_channel_req: channel 0 request subsystem reply 1
    debug1: session_by_channel: session 0 channel 0
    debug1: session_input_channel_req: session 0 req subsystem
    subsystem request for sftp
    debug1: subsystem: internal-sftp
    'ebug1: Forced command (config) 'internal-sftp
    debug1: Received SIGCHLD.
    debug1: session_by_pid: pid 11217
    debug1: session_exit_message: session 0 channel 0 pid 11217
    debug1: session_exit_message: release channel 0
    debug1: session_by_channel: session 0 channel 0
    debug1: session_close_by_channel: channel 0 child 0
    debug1: session_close: session 0 pid 0
    debug1: channel 0: free: server-session, nchannels 1
    Connection closed by xxxx
    debug1: do_cleanup
    Transferred: sent 2248, received 1504 bytes
    Closing connection to xxxx port 27730
    

    I think the bad part is somewhere along:

    debug1: subsystem: internal-sftp
    'ebug1: Forced command (config) 'internal-sftp
    debug1: Received SIGCHLD.
    

    Why does it send a SIGCHLD?

  • BAKABAKA Member
    edited September 2013

    Well imho I would prefer ftps (ftp with SSL) to sftp as for such need. But that config also takes a lot of pain.

  • @zsero why don't you just do what i said? That config works. Did you verify the user root directory ownership and permissions?

Sign In or Register to comment.