Пользователь не может SFTP после chroot

Ubuntu 10.04.4 LTS

Я пытаюсь chroot пользователя sam. Согласно всем статьям, это должно работать, но, видимо, я все еще делаю что-то не так.

Пользователь:

sam:x:1005:1006::/home/sam:/bin/false

Я изменил / etc / ssh / sshd_config вот так (внизу файла):

#Subsystem sftp /usr/lib/openssh/sftp-server
# CHROOT JAIL
Subsystem sftp internal-sftp
Match group users
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Я добавил Сэма в группу пользователей:

$groups sam
sam : sam users

Я изменил права доступа к домашней папке Сэма:

$ ls -la /home/sam
drwxr-xr-x 11 root root  4096 Sep 23 16:12 .
drwxr-xr-x  8 root root  4096 Sep 22 16:29 ..
drwxr-xr-x  2 sam  users 4096 Sep 23 16:10 awstats
drwxr-xr-x  3 sam  users 4096 Sep 23 16:10 etc
...
drwxr-xr-x  2 sam  users 4096 Sep 23 16:10 homes
drwxr-x---  3 sam  users 4096 Sep 23 16:10 public_html

Я перезапустил ssh, и теперь Сэм не может войти в систему через SFTP. Сессия создается, но также сразу закрывается:

Sep 24 12:55:15 ... sshd[9917]: Accepted password for sam from  ...
Sep 24 12:55:15 ... sshd[9917]: pam_unix(sshd:session): session opened for user sam  by (uid=0)
Sep 24 12:55:16 ... sshd[9928]: subsystem request for sftp
Sep 24 12:55:17 ... sshd[9917]: pam_unix(sshd:session): session closed for user sam

Cyberduck говорит Unexpected end of sftp stream. и другие клиенты выдают похожие ошибки.

Что я забыл / что не так?

Спасибо!

редактировать

Я не мог заставить его работать, даже связавшись со списком рассылки OpenSSH, поэтому решил перезагрузить весь свой сервер (к счастью, это был жизнеспособный вариант). Теперь работает.

sftp chroot

Centos 7 - у меня была такая же проблема - я пробовал все под солнцем, чтобы диагностировать ее - в конце концов я изменил подсистему sftp в '/ etc / ssh / sshd_conf', перезапустил sshd (service sshd restart) и проблема была исправлена:

Из :

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

Кому:

Subsystem sftp internal-sftp

Понятия не имею, зачем предусмотрены две реализации

Ваша установка определенно выглядит хорошо, давайте посмотрим, сможем ли мы выяснить, в чем проблема.

Убедитесь, что ваша версия openSSH поддерживает ChrootDirectory:

Поддержка ChrootDirectory ключевое слово было добавлено в openSSH версии 4.8p1 ( http://www.debian-administration.org/articles/590 ). Убедитесь, что установлена хотя бы эта версия:
```
dpkg --list openssh-server
```
[Вероятно, причина не в этом, по мнению http://releases.ubuntu.com/lucid/ubuntu-10.04.4-server-amd64.list версия openssh-server - 5.3p1]
Протестируйте SFTP локально.

Введите терминал на вашем компьютере с Ubuntu:
```
sftp sam@localhost
```
и посмотрите, можете ли вы войти в систему (вы должны ввести пароль Сэма, когда вас спросят). Если он работает, возможно, проблема в конфигурации Cyberduck.

Если вы не можете войти, попробуйте SFTP без chroot.
Протестируйте SFTP локально без chroot.

Префикс это:
```
Match group users
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
```
с участием # чтобы закомментировать это, перезапустите sshd (sudo service ssh restart), а затем введите:
```
sftp sam@localhost
```
Введите пароль, когда его спросят, и посмотрите, сможете ли вы войти в систему. Если вы можете войти в систему, устраните неполадки конфигурации chroot следующим образом: повторите шаг 2 с помощью команды sftp -vvv sam@localhost для подробного вывода. Вы также можете увеличить sshdуровень журнала, добавив LogLevel VERBOSE к /etc/ssh/sshd_config и перезапуск sshd. Надеюсь, вы увидите что-то очевидное в консоли или в /var/log/auth.log.

Если вы не можете войти, попробуйте SSH.
Протестируйте SSH локально.

SFTP требует работающего SSH, поэтому измените оболочку sam на / bin / bash:
```
sudo usermod -s /bin/bash sam
```
и попробуйте:
```
ssh sam@localhost
```
При запросе введите пароль Сэма. Если вы можете войти в систему, попробуйте увеличить подробность, как описано в разделе 3), чтобы выяснить, что не так (sftp -vvv sam@localhost и LogLevel VERBOSE в /etc/ssh/sshd_config). Другая возможность заключается в том, что инициализация оболочки сбивает с толку клиента sftp ( http://www.openssh.org/faq.html#2.9 ):
2.9 - sftp / scp не работает при подключении, но ssh в порядке.

sftp и / или scp могут выйти из строя во время подключения, если у вас есть инициализация оболочки (.profile, .bashrc, .cshrc и т. д.), которая производит вывод для неинтерактивных сеансов. Этот вывод сбивает с толку клиента sftp / scp. Вы можете проверить, делает ли это ваша оболочка, выполнив:
```
ssh yourhost /usr/bin/true
```
Если приведенная выше команда производит какой-либо вывод, вам необходимо изменить инициализацию оболочки.
Если вы не можете войти, попробуйте ssh root@localhost. Если не работает, то с sshd на сервере. Увеличить многословие (LogLevel VERBOSE в /etc/ssh/sshd_config), начать сначала sshd и просмотреть /var/log/auth.log, ответ, наверное, есть.

Несмотря на то, что ответ Жауме очень приятный, в конце концов он мне не помог. Я попробовал список рассылки OpenSSH, но безуспешно. В итоге я перезагрузил весь свой сервер, что, к счастью, смог сделать. Теперь он работает отлично.

У меня была такая же проблема, которую разрешили путем установки chroot-dir на корень владельца и корень группы.

chown root:root chroot-dir

Для ошибки «соединение отказано» проверьте настройку «UsePAM yes» в sshd_config. Это должно быть ДО "Подсистемы sftp"
В случае проблем с аутентификацией убедитесь, что КАЖДЫЙ каталог в chroot-path принадлежит пользователю root и имеет разрешения 755 или меньше.

Пример: ChrootDirectory / var / www / data

Вы должны проверить разрешения и владельца для: / var, / var / www, / var / www / data

При странных проблемах типа «соединение закрыто после аутентификации» попробуйте обновить или изменить SFTP-сервер.

apt-get установить openssh-server

«Подсистема sftp internal-sftp» <-> «Подсистема sftp / usr / lib / openssh / sftp-server» (переключитесь с типа с вашими проблемами на другой)