Home / server / Questions / 237552
Accepted
Shoaibi
Asked: 2011-02-19 19:53:50 +0800 CST

Can't get Passwordless (SSH provided) SFTP working

  • 772

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.

linux debian ssh sftp

4 Answers

  1. Best Answer

    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.

    • 6

  2. 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
    • 2

  3. 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.

    • 1

  4. 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.

    • 0