Я настроил sshd_conf в своем поле centos, как показано ниже:
Match group pilots
ChrootDirectory /home/pilots
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
и каталог / home / pilots вот так:
# ls -al /home/pilots
total 12
drwxr-x---. 3 root pilots 4096 Mar 10 14:20 .
drwxr-xr-x. 7 root root 4096 Mar 10 14:10 ..
drwxrwxr-x. 2 root pilots 4096 Mar 10 15:21 data
-rwxrwxrwx. 1 root root 0 Mar 10 14:20 topLevel
#
Если я sftp в качестве пользователя в группе pilots БЕЗ включенной директивы ChrootDirectory, я могу перейти в папку / home / pilots (или ее подкаталог) и без труда выполнить команду ls или получить. Однако, если я включу директиву ChrootDirectory, хотя я все еще могу войти в sftp и могу записать данные, я не могу выполнить команду ls или попасть в любой каталог. Например, попытка ls дает удаленный каталог чтения ("/"): Permission denied error, а попытка получить topLevel дает File "/ topLevel" not found. Я подумал, что, может быть, меня не было в каталоге, который я ожидал, но возможность записать данные на компакт-диск будет указывать на то, что chroot работает должным образом.
глядя на журнал сообщений, я вижу следующее, когда ls отклоняется:
type=1400 audit(1394494944.504:50): avc: denied { read } for pid=22758 comm="sshd" name="pilots" dev=dm-0 ino=400504 scontext=unconfined_u:system_r:chroot_user_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:home_root_t:s0 tclass=dir
Итак, есть запись об отрицании. Однако все еще не говорит мне, почему.
Что я делаю не так?
Пара потенциально важных замечаний:
Изменить: при дальнейшем исследовании выясняется, что это связано с SELinux - выполнение echo 0 >/selinux/enforce исправляет проблему, хотя и неуклюже, убивая муравья кувалдой. Если возможно, хотелось бы узнать «правильное» исправление.
Я нашел решение на эта страница. Подводя итог, после настройки sftp в соответствии с приведенной выше конфигурацией необходимо было выполнить следующие две команды, чтобы разрешить доступ с включенным SELinux:
setsebool -P ssh_chroot_rw_homedirs on
restorecon -R /home/$USERNAME
В этом случае вторая команда будет restorecon -R /home/pilots. После этого sftp работает, как ожидалось, даже в режиме chroot, без необходимости полностью отключать SELinux.
Уходя от @ ibrewster's ответ (в том числе внешний ресурс он связан с), вот полный набор инструкций с этой внешней страницы с некоторой добавленной информацией, чтобы заставить эту работу работать с входом без пароля и принудительным использованием SELinux.
Репост здесь на случай, если внешняя ссылка исчезнет в будущем.
Эти инструкции применимы к RHEL7 и CentOS7 (и, возможно, к другим выпускам):
Сначала добавьте и настройте учетную запись пользователя для chrooted:
Обратите внимание, что внешний ресурс использовал другой путь для sftp-server. Убедитесь, что у вас правильный путь в вашей системе, или приготовьтесь к боли. ;-) Указанный ниже путь подходит для минимальной установки RHEL7 и CentOS7.
# From command line:
groupadd sftponly
useradd -d /home/$USERNAME -s /usr/libexec/openssh/sftp-server -M -N -g sftponly $USERNAME
mkdir -p /home/$USERNAME/uploads /home/$USERNAME/downloads /home/$USERNAME/.ssh
chown $USERNAME:sftponly /home/$USERNAME/uploads /home/$USERNAME/downloads /home/$USERNAME/.ssh
chown root /home/$USERNAME
chmod 755 /home/$USERNAME
chmod 700 /home/$USERNAME/.ssh
passwd $USERNAME
echo '/usr/libexec/openssh/sftp-server' >> /etc/shells
Хотя я установил пароль выше, я буду использовать вход без пароля, как только узнаю, что конфигурация работает. Вперед ...
Предполагая, что у вас есть SELinux включен и принудительно (вы должны), введите эти команды, чтобы сделать его счастливым:
setsebool -P ssh_chroot_rw_homedirs on
restorecon -R /home/$USERNAME
Теперь отредактируйте конфигурацию sshd следующим образом:
[root@remote]# vi /etc/ssh/sshd_config
#
# CHANGE lines:
#
# override default of no subsystems
#Subsystem sftp /usr/libexec/openssh/sftp-server # commented out
Subsystem sftp internal-sftp # added
#
# ADD the following at the bottom:
#
Match group sftponly
ChrootDirectory %h
AllowTcpForwarding no
ForceCommand internal-sftp
Наконец, перезапустите sshd
[root@remote]# systemctl restart sshd.service
Сначала создайте ту же учетную запись локально.
[root@client]# useradd -m $USERNAME
[root@client]# passwd $USERNAME
[root@client]# su $USERNAME
Хорошо, теперь давайте настроим нашу пару ключей RSA.
[$USERNAME@client]# ssh-keygen
Мне не удалось заставить ssh-copy-id работать с конфигурацией chroot выше, поэтому я вручную создал authorized_keys файл с текстом id_rsa.pub моего клиента.
[$USERNAME@client]# cat .ssh/id_rsa.pub
---some key here---
Затем вернитесь к системе REMOTE,
[root@remote]# vi /home/$USERNAME/.ssh/authorized_keys
---past key from right above, then wq---
Не забудьте установить права доступа к этому файлу:
[root@remote]# chown $USERNAME:sftpusers /home/$USERNAME/.ssh/authorized_keys
Теперь все должно быть на месте. От клиента:
[$USERNAME@client]# sftp $USERNAME@remote
Это должно помочь вам войти. Если вам будет предложено ввести пароль (мы еще не отключили аутентификацию PasswordAuthentication на пульте дистанционного управления), у вас есть проблема с конфигурацией удаленной системы. Отсканируйте ваш / var / log / secure для получения подробной информации.
Если вы войдете в систему без запроса пароля, вы почти закончили.
[root@remote]# vi /etc/ssh/sshd_config
# disable PasswordAuthentication
PasswordAuthentication no
# or optionally, just comment that line out
# PasswordAuthentication no
-- save and exit with :wq --
Перезапустите sshd в удаленной системе:
[root@remote]# systemctl restart sshd.service
[$USERNAME@client]# sftp $USERNAME@remote
# in like Flynn? yay!
Вы должны быть готовы пойти с chroot sftp и вход без пароля (с участием SELinux установлен в принуждение)