I have a home web server using SSH on a custom port. I've found that if I go to sftp://domainname.tld:port my whole filesystem is visible, and anybody can download any file. I'd like to chroot this to my public_html directory, but my additions don't seem to be making any difference after restarting the service. My additions in sshd_config are as follows:

Subsystem       sftp    /usr/lib/openssh/sftp-server
Subsystem       sftp    internal-sftp

ChrootDirectory /path/public_html/
ForceCommand internal-sftp
AllowTcpForwarding no

A link to where I can read up on the documentation for SSH configurations would also be very appreciated.

EDIT: I accidentally left out an important piece of information (I think). I'm talking about when someone visits sftp://domainname.tld:port in a web browser, not with an SFTP program. I'm getting this behavior from Firefox on Linux Mint.

  • Anybody? I'm fairly positive sftp relies on ssh, meaning they have to have a valid account on your server, and sever side permissions are followed. – demure May 30 '13 at 16:36
  • I was under that impression too. I'm not really sure what it is (probably not anonymous SFTP), but I'd just like to be able to chroot it. – user195213 May 30 '13 at 16:38
  • Just to clarify the cause, it was an unstable SSH process that eventually crashed. The solution was to simply kill the process and restart it. – user195213 May 31 '13 at 2:26

Add something like :

Match user restricted_user
    ChrootDirectory /home/chrooted
    ForceCommand internal-sftp

to /etc/ssh/sshd_config.

restricted_user can not use an ssh shell any more :

$ ssh -o Port=some_port restricted_user@domainname.tld
restricted_user@domainname.tld's password:
This service allows sftp connections only.
Connection to domainname.tld closed.

It seems that ssh is very picky about the access right of the directory. If the connection fails with an Write failed: Connection reset by peer error, you can usually look in /var/log/auth or /var/log/secure to know what happened.

See https://wiki.archlinux.org/index.php/SFTP-chroot for more details.

| improve this answer | |
  • Thanks for the input, but I left out an important piece of information. Will this work for web browsers as well, or is this another problem? – user195213 May 31 '13 at 1:43
  • That was odd. I got home from work and SSH had crashed while I was gone. I simply killed the defunct processes and restarted it, and now it's asking for a username and password when I try to access the website via SFTP through a browser. You gave the best answer for my question, so I'll accept yours. Thanks again for the detailed response and link to docs. – user195213 May 31 '13 at 2:25

As it should. SFTP functions over SSH, so you should be able see any file that the user you logged in as has read access to. Even if you did chroot SFTP, the user could just log in using SSH instead and read the file.

and anybody can download any file

Incorrect; Anybody with a user account on the system can download any file that their user has permission to read.

SFTP doesn't have anonymous access in the same way FTP does, and any actions taken can always be tied back to a specific user registered on your system. If you want to secure your system, use strong passwords, limit IP ranges that can connect over SSH, watch for failed login attempts, etc.

| improve this answer | |
  • Thanks for the input, but I left out an important piece of information. Does this change your answer to this problem? – user195213 May 31 '13 at 1:43
  • Just worth mentioning that your answer specifically applies to how OpenSSH SFTP works/is implemented. These restrictions/behaviour (that you see all files, that what you see is more or less determined by the SSH server config, that there's no anonymous account) are not inherent to SFTP in general. – Martin Prikryl Jun 1 '13 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy