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

Ubuntu 10.04.4 LTS

Я пытаюсь найти пользователя "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

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

$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, и теперь sam не может войти через 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

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

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

Спасибо!

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

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

Источник

5 ответов

Решение

Несмотря на то, что ответ Джоми очень хороший, он не мог помочь мне в конце. Я попробовал список рассылки OpenSSH, но не повезло. Я перезагружал весь свой сервер, что я все еще мог сделать к счастью. Сейчас работает отлично.

Источник

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

  1. Убедитесь, что ваша версия 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-сервера - 5.3p1]

  2. Проверьте SFTP локально.

    Введите терминал на вашем компьютере Ubuntu:

    sftp sam@localhost

    и посмотреть, можете ли вы войти в систему (вы должны ввести пароль sam при запросе). Если это работает, может быть проблема с конфигурацией Cyberduck.

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

  3. Протестируйте 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.

  4. Проверьте 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 - ошибка 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, ответ, вероятно, там.

Источник

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

От:

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

Кому:

Subsystem sftp internal-sftp

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

Источник

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

chown root:root chroot-dir

Источник

  1. Для ошибки "Отказано в соединении" проверьте параметр "UsePAM yes" в sshd_config. Должно быть ДО "Подсистема sftp"

  2. Для проблем аутентификации проверьте, что КАЖДЫЙ каталог в chroot-path принадлежит root и имеет разрешения 755 или меньше.

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

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

  1. Для странных проблем типа "соединение закрыто после аутентификации" попробуйте обновить или изменить SFTP-сервер.

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

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

Источник
Другие вопросы по тегам