How to create chroot'ed SFTP access on an Archlinux Server?

Question

I've followed this instructions on the ArchWiki and GeekStuff to setup an user which can only access the server via SFTP (SSH) but without Shell (/bin/false) in a chrooted environment of his home dir.

Nothing much more special, but it simply does not work, I keep getting access denied messages when I try to log in. Here is what I've tried so far:

SFTP User and Group

The user, here: user, is member of the group sftp. Home directory is /srv/sftp/user. Shell is disable via /bin/false

User entry:

0 ✓ root@host ~ $ grep -i user /etc/passwd
user:x:1002:1000::/srv/sftp/user:/bin/false

Group entry:

0 ✓ root@host ~ $ grep -i sftp /etc/group
sftp:x:1000:user

Groups of user:

0 ✓ root@host ~ $ groups user
users sftp

Home Directory Configuration

The home directory and all directories above are owned by root:

0 ✓ root@host ~ $ ls -lsha /srv
total 20K
4,0K drwxr-xr-x  6 root root 4,0K  4. Apr 17:00 ./
4,0K drwxr-xr-x 17 root root 4,0K  4. Apr 15:08 ../
4,0K dr-xr-xr-x  2 root ftp  4,0K 30. Sep 2015  ftp/
4,0K drwxr-xr-x  4 root root 4,0K  4. Apr 19:30 http/
4,0K drwxr-xr-x  5 root root 4,0K  4. Apr 17:00 sftp/
0 ✓ root@host ~ $ ls -lsha /srv/sftp
total 12K
4,0K drwxr-xr-x 5 root root 4,0K  4. Apr 17:00 ./
4,0K drwxr-xr-x 6 root root 4,0K  4. Apr 17:00 ../
4,0K drwxr-xr-x 5 root root 4,0K  4. Apr 19:34 user/
0 ✓ root@host ~ $ ls -lsha /srv/sftp/user
total 16K
4,0K drwxr-xr-x 5 root root 4,0K  4. Apr 19:34 ./
4,0K drwxr-xr-x 5 root root 4,0K  4. Apr 17:00 ../
4,0K drwxrwxr-x 6 user sftp 4,0K  4. Apr 20:28 files/
4,0K drwxrwxr-x 2 user sftp 4,0K  4. Apr 19:33 log/

SSHD Configuration

The end of the SSHD config:

0 ✓ root@host ~ $ tail -n16 /etc/ssh/sshd_config 
# override default of no subsystems
### Subsystem   sftp    /usr/lib/ssh/sftp-server
Subsystem       sftp    internal-sftp

### This section must be placed at the very end of sshd_config
#   This means that all users in the ‘sftp’ group will be chroot’d
#   to their home directory, where they only will be able to run
#   internal SFTP processes.
Match Group sftp
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    PermitTunnel no
    X11Forwarding no
    PasswordAuthentication yes

SSHD status:

0 ✓ root@host ~ $ systemctl status sshd
● sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mo 2016-04-04 23:48:58 CEST; 1 day 15h ago
 Main PID: 9272 (sshd)
    Tasks: 3 (limit: 512)
   CGroup: /system.slice/sshd.service
           ├─ 9272 /usr/bin/sshd -D
           ├─17597 sshd: user [priv]  
           └─17598 sshd: user [net]   
[...]
Apr 06 15:05:24 host sshd[17597]: Failed password for user from 93.***.***.136 port 45516 ssh2

OpenSSH version:

0 ✓ root@host ~ $ pacman -Q openssh
openssh 7.2p2-1

More system information

Kernel version:

0 ✓ root@host ~ $ uname -a
Linux host 4.4.5-1-ARCH #1 SMP PREEMPT Thu Mar 10 07:38:19 CET 2016 x86_64 GNU/Linux

Trying to connect

To make sure the password is really correct, I change it to 1234:

0 ✓ root@host ~ $ passwd user
Enter new UNIX password: 1234
Retype new UNIX password: 1234
passwd: password updated successfully

Now test with sftp:

1 ✗ me@client ~ $ sftp -P12345 user@host
user@host's password: 1234
Permission denied, please try again.
user@host's password: 1234
Permission denied, please try again.
user@host's password: 1234
Permission denied (publickey,password).
Couldn't read packet: Connection reset by peer

This is in the logs, not really helpful at all:

0 ✓ root@host ~ $ journalctl -n5
Apr 06 15:34:38 host passwd[25269]: pam_unix(passwd:chauthtok): password changed for user
Apr 06 15:35:26 host sshd[25853]: Failed password for user from 93.***.***.136 port 45834 ssh2
Apr 06 15:35:30 host sshd[25853]: Failed password for user from 93.***.***.136 port 45834 ssh2
Apr 06 15:35:33 host sshd[25853]: Failed password for user from 93.***.***.136 port 45834 ssh2
Apr 06 15:35:34 host sshd[25853]: Connection closed by 93.***.***.136 port 45834 [preauth]

What am I doing wrong? What did I miss? How to create chroot'ed SFTP access on an Archlinux Server wihtout shell access?

make sure you restart `sshd` after changes in config. Can you login locally with that user? Does it work if you change `/bin/false` to `/bin/sh`? — Jakuje, Apr 06 '16 at 16:35
`sshd` restarted, if I change shell to `/bin/sh` it works. but i dont want to permit shell access. — q9f, Apr 14 '16 at 11:02
`ForceCommand internal-sftp` prohibits shell access. Also if the shell itself is not in `chroot`, it would not be useful. — Jakuje, Apr 14 '16 at 11:08
ok, found the solution, `/bin/false` was [missing](http://serverfault.com/a/268981/116529) in `/etc/shells`... just took me 2 weeks to find out. — q9f, Apr 14 '16 at 11:33
didnt know `internal-sftp` prohibits shell access. thanks for the pointer to the shell. — q9f, Apr 14 '16 at 11:34
Using `/sbin/nologin` is maybe more appropriate, since it is in `/etc/shells`. — Jakuje, Apr 14 '16 at 11:34

score 0 · Accepted Answer · answered Apr 14 '16 at 11:45

Ok, the point I missed has something to do with the shell. I tried to login with /bin/false as described in many manuals. But that didn't work.

As @Jakuje pointed out, changing that to /bin/sh for testing purposes allowed me to login via sftp. Hurray! And the interesting fact I also didn't know: internal-sftp already prevents ssh login.

However, who still want's /bin/false or /bin/nologin as shell, here is what I figured out, finally. Check out if the shells are available in /etc/shells:

0 ✓ root@host ~ $ cat /etc/shells 
#
# /etc/shells
#

/bin/sh
/bin/bash

# End of file

No wonder it didn't work! false and nologin are not defined! Adding them manually worked out for me:

0 ✓ root@host ~ $ cat /etc/shells 
#
# /etc/shells
#

/bin/sh
/bin/bash
/bin/false
/bin/nologin

# End of file

Now, just change the shell, with chsh:

0 ✓ root@host ~ $ chsh -s /bin/false user
Changing shell for user.
Shell changed.

Now, sftp works in a change-rooted environment and without shell access.