Mailing List Archive

Alex Jurkiewicz wrote:
> Hi all,
>
> I'm having problems with a chrooted sftp set up. I can connect with
> the psftp program from the Putty toolkit, but not with the standard
> sftp utility.
> OpenSSH is the same on the client and server:
> OpenSSH_5.1p1Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
>
> My server configuration is as follows:
>
> sshd_config contains (among other things):

Those "other things" could well be the source of the problem, since
Match works first-match per config directive.

[...]
> Connecting with psftp works, here is the sshd log:
> http://www.bluebottle.net.au/putty-sshd.txt
> And the client log:
> http://www.bluebottle.net.au/putty-psftp.txt

No, it has the same problem with sftp but falls back to using a shell,
which works:

Opened channel for session
Primary command failed; attempting fallback
Started a shell/command

> However, connecting with sftp(1) doesn't, see the two logs here:
> http://www.bluebottle.net.au/sftp-sshd.txt
> http://www.bluebottle.net.au/sftp-sftp.txt
>
> I'm not quite sure why this isn't working, is sftp failing to send a
> needed command?

No, your server config is probably broken:

subsystem request for sftp
subsystem: cannot stat /usr/lib/openssh/sftp-server: No such file or
directory

however since you've trimmed the server logs you've removed the parts
that would have shown what Match did, so I have no idea what happened.

Please either post your entire config (or reduce your config to a subset
that you are willing to post), repeat the test with that config (use
sshd -f reduced_config if you don't use your real config) and show the
entire log.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

2009/7/22 Darren Tucker <dtucker@zip.com.au>:
>> Connecting with psftp works, here is the sshd log:
>> http://www.bluebottle.net.au/putty-sshd.txt
>> And the client log:
>> http://www.bluebottle.net.au/putty-psftp.txt
>
> No, it has the same problem with sftp but falls back to using a shell, which
> works:
>
> Opened channel for session
> Primary command failed; attempting fallback
> Started a shell/command

Out of interest, how is this shell created? The default shell is
/bin/false, and sending a command through with ssh (eg `ssh
user@server ls -l .`) does nothing.

[...]
> No, your server config is probably broken:
>
> subsystem request for sftp
> subsystem: cannot stat /usr/lib/openssh/sftp-server: No such file or
> directory
>
> however since you've trimmed the server logs you've removed the parts that
> would have shown what Match did, so I have no idea what happened.
>
> Please either post your entire config (or reduce your config to a subset
> that you are willing to post), repeat the test with that config (use sshd -f
> reduced_config if you don't use your real config) and show the entire log.

Sure,
http://www.bluebottle.net.au/sshd_config.txt
http://www.bluebottle.net.au/sftp-sshd-full.txt
http://www.bluebottle.net.au/sftp-sftp-full.txt

Now that I know psftp is doing special stuff to get a 'sftp' session
working, is the issue something relating to sftp-server not being in
the chroot? The sshd_config manpage entry for ChrootDirectory seems to
state this isn't neccessary, but I could be misreading.

AJ

2009/7/22 Richard L Ross <rross@us.ibm.com>:
> Your sshd_config is setup correctly, but "user" home directory in
> /etc/passwd is pointing to the chroot'ed directoy .. If you create a new
> home directory under /home/user/home and vi /etc/passwd to change the home
> directory to just "/home" it should work (Once ssh sets up the chrooted
> environment, it will cd to the home directory inside of the chroot) Make
> sure that "user" is the owner of /home/user/home and make sure you "vi"
> /etc/passwd to make the change to the home directory
>
> I usually setup additional directories under /home/$userid/home to have the
> user place their data .. then set the guid bit to have a admin type be able
> to retrieve the file
>
> This is the normal flow I would use:
>
> mkdir /home/$userid/home
> chown root:root /home/$userid
> chown $userid:$group-admin /home/$userid/home/
> vi /etc/passwd to change the home directory to /home and shell to /bin/false

Thanks for the hints, I'm on the right track.

Sadly your setup doesn't work perfectly: for one thing changing the
user's homedir to /home means that OpenSSH looks for the
authorized_keys file in /home/.ssh in the root filesystem! I suppose
this would be less of/not an issue if you used password auth, but I
can't.

What did work was this:
* Unchanged sshd_config
* User's home directory is /home/user (in /etc/passwd)
* chown root:root /home/user
* mkdir -p /home/user/usr/lib/openssh/
* cp /usr/lib/openssh/sftp-server /home/user/usr/lib/openssh/sftp-server

When you authenticate you appear chrooted in /home/user. The obvious
problem is that the user's homedir isn't writeable by them, so you
have to pre-populate subdirectories.

I'm still confused on several points though:
1. Why do I need to copy sftp-server into the chroot? The
sshd_config(5) entry for ChrootDirectory states: "For file transfer
sessions using ``sftp'', no additional configuration of the
environment is necessary if the in-process sftp server is used (see
Subsystem for details).".
1b. Are /usr/lib/openssh/sftp-server and internal-sftp different names
for the same thing?
2. Does the method I worked out above have any security issues?
3. Is there any way I can use ChrootDirectory with a user-writable
home directory?

Thanks,
AJ