6

I have configured an sftp server with chroot and it works fine, the only thing that is bothering me is the initial landing directory, since the sftp user does not have write permissions in the landing folder he has to go to a folder named after his own username to upload files.

I have set: ForceCommand internal-sftp -d %u, which I found in some configuration guides and they said that it should change the landing folder, but it does not work. At the beginning I had configured a null script for the user login at passwd, but I changed it to /bin/bash in case that it might have had something to do with this. I rebooted the service, so it might not be that the cause also.

Perhaps it might be related to the version of ssh that the distribution I'm using has or perhaps sshd cannot do this at all?

Here is my configuration regarding to sshd:

CentOS release 6.6 (Final)

OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 201

Subsystem sftp internal-sftp

Match group sftponly
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp -d %u
Carles Estevadeordal
  • 163
  • 1
  • 5

1 Answers1

5

You can use option -d of sftp which changes the starting directory for you. See sftp-server(8) manual page:

-d start_directory

specifies an alternate starting directory for users. The pathname may contain the following tokens that are expanded at runtime: %% is replaced by a literal '%', %h is replaced by the home directory of the user being authenticated, and %u is replaced by the username of that user. The default is to use the user's home directory. This option is useful in conjunction with the sshd_config(5) ChrootDirectory option.

You can do this by putting this as an argument to internal-sftp, for example:

Subsystem sftp internal-sftp -d "%h/sftp_home/"

Additionally, you might need to adjust your force-command, if you use one:

 ForceCommand internal-sftp -d "%h/sftp_home/"

This should be available on openssh since version 6.2

Jakuje
  • 9,715
  • 2
  • 42
  • 45
  • Found this today, was driving me nuts that this wasn't working until I dug into the OpenSSH release notes for v6.2: http://www.openssh.com/txt/release-6.2 Thanks! – Ryder Jun 22 '16 at 16:06
  • 1
    @Ryder we have upvotes for that ;) – Jakuje Jun 27 '16 at 21:13
  • 1
    Omg— we do? We do! @Jakuje saves the day again. – Ryder Jun 27 '16 at 21:15
  • OP states 5.3 not 6.2, is there a workaround for 5.3 – Ura Apr 19 '17 at 20:27
  • @Dejan none I would be aware of. It might work if you do not use `internal-sftp`, but the real `sftp-server` together with some `cd`, but I didn't try that. OpenSSH 5.3 is already very old so it is advised to use more recent versions and systems when setting up some new infrastructure or configure the client. – Jakuje Apr 19 '17 at 20:32
  • If you mean update, I meant the whole system to RHEL7 ... – Jakuje Apr 20 '17 at 15:09
  • 3
    This didn't quite work for me on `OpenSSH_7.3p1 Ubuntu-1, OpenSSL 1.0.2g 1 Mar 2016`. What did work was specifying `Subsystem sftp internal-sftp` (no additional arguments) and then `ForceCommand internal-sftp -d {dir_relative_to_chroot}`. – Vic Sep 26 '17 at 09:46
  • @Vic's solution is the only one that worked for me. I'm embarrassed to say how long I searched for this answer. – Gojira Jul 05 '18 at 21:42
  • The only important difference is to use `%h/` instead of `%h`. Changing the `Subsystem sftp...` line is not necessary. – mgutt Aug 24 '22 at 20:13