Не может получить Passwordless (обеспеченный SSH) работа SFTP
Daemontools DJB может сделать точно, что Вы хотите.
Однако это было бы более продуктивно в конечном счете, если Вы могли бы выяснить, почему вещи умирают и фиксируют причину, не признак.
Прежде всего, корневые каталоги в /etc/passwd должен отразить пути un-chrooted, или Вы столкнетесь с проблемами в целом. В этом случае, sshd проверки на авторизованные ключи перед ним chroots, таким образом, это должно найти их использующий путь un-chrooted. Вот почему Ваша первая попытка не работает.
Вторая вещь отметить: При Вашей первой установке, когда david входит в систему, он запускает в /var/chroot-home/david, но он на самом деле chrooted к /var/chroot-home, значение, если он вводит cd .. он видит всех других домашних директоров (хотя не их содержание, если полномочия корректны). Этот мог бы или не могла бы быть проблема для Вас, но это - хорошая вещь знать.
Если вышеупомянутое соглашается с Вами, можно использовать первый sshd_config, установить домашний dir david на /var/chroot-home/david в passwd файл, и добавляет следующую символьную ссылку так, чтобы david все еще запустился в его корневом каталоге:
cd /var/chroot-home
mkdir var
ln -s .. var/chroot-home
Та символьная ссылка удостоверится, что можно достигнуть корневого каталога с помощью того же пути, являетесь ли Вы в chroot.
Однако, если Вы не хотите, чтобы клиенты видели названия корневых каталогов друг друга, Вам нужно к chroot в сам корневой каталог, как в Вашем втором решении. Но поскольку Вы видели, sshd не любит это (потому что по различным тонким причинам, опасно дать пользовательский доступ для записи к корню файловой системы). К сожалению, Вам главным образом не повезло здесь. Одно (топорное) решение этого состоит в том, чтобы создать a files/ подкаталог в каждом корневом каталоге и дает клиентский доступ для записи к этому вместо этого.
Другая опция могла бы быть к chroot к/var/chroot-home так или иначе и назвать корневые каталоги по-другому, например, использование числа идентификатора пользователя вместо имени.
Вы проверили полномочия файла на .ssh и authorized_keys?
drwx------ .ssh/ (chmod 0700)
-rw------- .ssh/authorized_keys (chomd 0600)
Это может быть очевидно, но иногда это пропущено.
Необходимо создать подкаталог в chroot пользователя домой (/var/chroot-home/david/incoming или безотносительно) и затем chown david:clients incoming и дайте соответствующие разрешения с chmod 755 incoming.
См. это сообщение для деталей.
Я нашел, что должен был создать chroot домой (как описано выше), но также и реальный дом (/home/david), чтобы хранить их .ssh/authorized_keys файл. Я полагаю, что это вызвано тем, что аутентификация SSH происходит прежде chroot, таким образом, sshd не знает, чтобы там искать .ssh файл.
Думая об этом теперь, я, вероятно, попробую еще раз при помощи их реальных корневых каталогов как их chroot домой: все еще потребность создать incoming папка, но по крайней мере .ssh будет то, где это ожидается.
Я решил эту проблему, используя следующее:
AuthorizedKeysFile /sftp/%u/.ssh/authorized_keys
Где% u - это зарегистрированный пользователь chRooted, который ведет журнал.
Match Group sftp
ChrootDirectory /sftp/%u