Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have chrooted sftp setup as below.

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes
AllowGroups admins clients

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

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

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes



Subsystem sftp internal-sftp

Match group clients
    ChrootDirectory /var/chroot-home
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

a dummy user

root:~# tail -n1 /etc/passwd
david:x:1000:1001::/david:/bin/sh

Now in this case david can sftp using say filezilla client and he is chrooted to /var/chroot-home/david/. But what if i was to setup a passwordless auth? I have tried pasting his key in /var/chroot-home/david/.ssh/authorized_keys but no use, tried ssh'ing as david to the box and it just stops at "debug1: Sending env LC_CTYPE = C" after i supply it password and there is nothing shown in auth.log, may be because it can't find the homedir. If i do "su - david" as root i see "No directory, logging in with HOME=/" which makes sense. Symlink doesn't help either.

I have also tried with:

Match group clients
        ChrootDirectory /var/chroot-home/%u
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp

a dummy user

root:~# tail -n1 /etc/passwd
david:x:1000:1001::/var/chroot-home/david:/bin/sh

This way if i don't change /var/chroot-home/david to root:root sshd complains about bad ownership or permission modes, and if i do, david can no longer upload/delete anything directly in his home while using sftp from filezilla.

share|improve this question
    
Did you load the private key into filezilla or setup pageant ? –  Iain Feb 19 '11 at 11:07
1  
From the ssh config you're using the default key location #AuthorizedKeysFile %h/.ssh/authorized_keys, david's home is /david so the key must be in /david/.ssh/authorized_keys. The chroot take effect after authentication. Also, you mention "key", in SSH it is a key pair, two files, the public one goes in authorized_keys the private goes into Filezilla, or pagent, or whatever program he's using. –  Chris S Mar 28 '11 at 13:27

4 Answers 4

up vote 4 down vote accepted

First off, the home directories in /etc/passwd should reflect the un-chrooted paths, or you'll run into problems in general. In this case, sshd checks for authorized keys before it chroots, so it needs to find them using an un-chrooted path. That's why your first try doesn't work.

Second thing to note: Under your first setup, when david logs in he starts in /var/chroot-home/david, but he is actually chrooted to /var/chroot-home, meaning if he types cd .. he can see all of the other home dirs (although not their contents, if permissions are correct). This might or might not be a problem for you, but it's a good thing to be aware of.


If the above is fine with you, you can use your first sshd_config, set david's home dir to /var/chroot-home/david in the passwd file, and add the following symlink so that david still starts in his home directory:

cd /var/chroot-home
mkdir var
ln -s .. var/chroot-home

That symbolic link will make sure that you can reach a home directory using the same path whether or not you are in the chroot.


However, if you don't want the clients to see the names of each other's home directories, you need to chroot into the home directory itself, as in your second solution. But as you've seen, sshd doesn't like that (because for various subtle reasons, it's dangerous to give a user write access to the root of a filesystem). Sadly, you're mostly out of luck here. One (kludgy) solution to this is to create a files/ subdirectory in each home directory and give the client write access to that instead.

Another option might be to chroot to /var/chroot-home anyway, and name the home directories differently, e.g. using the user ID number instead of the name.

share|improve this answer

I solved this problem using this:

AuthorizedKeysFile /sftp/%u/.ssh/authorized_keys

Where %u is the chRooted user that is logging.

Match Group sftp
   ChrootDirectory /sftp/%u
share|improve this answer

Have you checked the file permissions for .ssh and authorized_keys?

drwx------   .ssh/                   (chmod 0700)
-rw-------   .ssh/authorized_keys    (chomd 0600)

It may be obvious, but sometimes it's overlooked.

share|improve this answer
    
already done. still asks me for password, so its certainly not reading /var/chroot-home/david/.ssh/authorized_key, ,may be cause homedir of that user is /david. Please go through my post once again to get a rough idea of what i am upto. –  Shoaibi Feb 19 '11 at 4:21

You need to create a sub-directory in the user's chroot home (/var/chroot-home/david/incoming or whatever) and then chown david:clients incoming and grant appropriate permissions with chmod 755 incoming.

See this post for details.

I found that I had to create a chroot home (as described above) but also a real home (/home/david) to store their .ssh/authorized_keys file. I believe this is because the SSH authentication happens before chroot, so the sshd doesn't know to look in there for the .ssh file.

Thinking about it now, I'll likely try again by using their real home directories as their chroot home: still need to create an incoming folder, but at least .ssh will be where it's expected.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.