Linux – Chroot In .bashrc For User; Operation Not Permitted

I guess, I am a bit late, but maybe someone stumbles upon this question as I did. So here we go...

As explained before by mgorven, if your FTP user does not own the files he cannot modify the timestamp to an arbitrary time (there is also a rather detailed answer here).

Now for WinSCP: you can disable the option "Preserve timestamps" under Options -> Preferences... -> Transfer. You can do the same for all your transfer profiles. Now WinSCP will not try to set modification times any more but it will just use the upload time instead (so this does not change any behavior but just gets you rid of the error messages). However, this will only work for single file uploads. Both the synchronization and the monitoring feature will ignore this setting if you set the comparison criterion to modification time (which Martin Prikryl confirmed here). And right now, unfortunately, there is nothing you can do about having to click away all those error messages when synchronizing.

Because I like to use both synchronization and monitoring (and especially the monitoring feature is actually more broken with the option enabled), I filed this feature request. Until that is accepted and implemented, I'm afraid, there is no practical no way to get rid of the error messages.

Your setup definitely looks good, let's see if we can find out where the problem is.

1. Check that your openSSH version supports ChrootDirectory:

   Support for the ChrootDirectory keyword was added to openSSH version 4.8p1 ( http://www.debian-administration.org/articles/590 ). Check that at least that version is installed:

   dpkg --list openssh-server
   

   [This is probably not the cause, according to http://releases.ubuntu.com/lucid/ubuntu-10.04.4-server-amd64.list openssh-server's version is 5.3p1]

2. Test SFTP locally.

   Type in a terminal on your Ubuntu computer:

   sftp sam@localhost
   

   and see whether you can log in (you must type sam's password when asked). If it works there may be a problem with Cyberduck's configuration.

   If you can't log in, try SFTP without chroot.

3. Test SFTP locally without chroot.

   Prefix this:

   Match group users
       ChrootDirectory %h
       ForceCommand internal-sftp
       AllowTcpForwarding no
   

   with # to comment it out, restart sshd (sudo service ssh restart) and then type:

   sftp sam@localhost
   

   Type the password when asked and see whether you can log in. If you can log in troubleshoot the chroot configuration as follows: try step 2 again with command sftp -vvv sam@localhost for verbose output. You can also increase sshd's log level by adding LogLevel VERBOSE to /etc/ssh/sshd_config and restarting sshd. Hopefully you see something obvious in the console or in /var/log/auth.log.

   If you can't log in, try SSH.

4. Test SSH locally.

   SFTP requires a working SSH, so change sam's shell to /bin/bash:

   sudo usermod -s /bin/bash sam
   

   and try:

   ssh sam@localhost
   

   Type sam's password when asked. If you can log in try increasing verbosity as explained in 3) to find out what's wrong (sftp -vvv sam@localhost and LogLevel VERBOSE in /etc/ssh/sshd_config). Another possibility is that the shell initialization confuses the sftp client ( http://www.openssh.org/faq.html#2.9 ):

   2.9 - sftp/scp fails at connection, but ssh is OK.

   sftp and/or scp may fail at connection time if you have shell initialization (.profile, .bashrc, .cshrc, etc) which produces output for non-interactive sessions. This output confuses the sftp/scp client. You can verify if your shell is doing this by executing:

   ssh yourhost /usr/bin/true
   

   If the above command produces any output, then you need to modify your shell initialization.

   If you can't log in, try ssh root@localhost. If doesn't work either there's something wrong with sshd on the server. Increase verbosity (LogLevel VERBOSE in /etc/ssh/sshd_config), restart sshd and peruse /var/log/auth.log, the answer is probably there.