Внезапный сбой SFTP для учетных записей chroot в Amazon Linux

К сожалению, пользователи SFTP внезапно перестали иметь возможность подключиться к моему Amazon Сервер Linux.

В / var / log / secure отображается следующая ошибка:

sshd[7291]: fatal: safely_chroot: stat("/chroot/uhleeka"): Permission denied [postauth]

/ var / log / secure:

==> /var/log/secure <==
Nov 21 23:49:23 amzl-lamp sshd[7291]: Accepted password for uhleeka from 172.31.0.254 port 47170 ssh2
Nov 21 23:49:24 amzl-lamp sshd[7291]: pam_unix(sshd:session): session opened for user uhleeka by (uid=0)
Nov 21 23:49:24 amzl-lamp sshd[7291]: fatal: safely_chroot: stat("/chroot/uhleeka"): Permission denied [postauth]
Nov 21 23:49:24 amzl-lamp sshd[7291]: pam_unix(sshd:session): session closed for user uhleeka

Отладочные данные с SSHD:

$ /usr/sbin/sshd -ddd -p 33333
...
debug1: SELinux support disabled
debug1: PAM: establishing credentials
debug3: PAM: opening session
debug1: monitor_reinit: /dev/log doesn't exist in /chroot/%u chroot - will try to log via monitor using [postauth] suffix
User child is on pid 6655
debug1: PAM: establishing credentials [postauth]
debug3: safely_chroot: checking '/' [postauth]
debug3: safely_chroot: checking '/chroot/' [postauth]
debug3: safely_chroot: checking '/chroot/uhleeka' [postauth]
safely_chroot: stat("/chroot/uhleeka"): Permission denied [postauth]
debug1: do_cleanup [postauth]
debug3: PAM: sshpam_thread_cleanup entering [postauth]
debug3: mm_request_send entering: type 124 [postauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 124
debug3: mm_request_receive entering
debug1: do_cleanup
debug1: PAM: cleanup
debug1: PAM: closing session
debug1: PAM: deleting credentials
debug3: PAM: sshpam_thread_cleanup entering

SELinux отключен:

$ sestatus
SELinux status:                 disabled

$ ls -lZ /chroot/uhleeka/
drwxr-x--- root root      ?                                .
drwx--x--- root sftp-only ?                                ..
drwx--x--- root sftp-only ?                                etc
drwxr-xr-x root sftp-only ?                                home

Не было изменений конфигурации или разрешения меняются, но вчера было запущено обновление yum:

$ rpm -qa --last
system-release-2016.09-0.8.noarch             Mon 21 Nov 2016 04:34:40 PM UTC
cloud-init-0.7.6-2.14.amzn1.noarch            Mon 21 Nov 2016 04:34:40 PM UTC
python26-botocore-1.4.74-1.60.amzn1.noarch    Mon 21 Nov 2016 04:34:39 PM UTC
openssh-server-6.6.1p1-31.62.amzn1.x86_64     Mon 21 Nov 2016 04:34:39 PM UTC
openssh-clients-6.6.1p1-31.62.amzn1.x86_64    Mon 21 Nov 2016 04:34:39 PM UTC
aws-cli-1.11.17-1.43.amzn1.noarch             Mon 21 Nov 2016 04:34:39 PM UTC
python27-botocore-1.4.74-1.60.amzn1.noarch    Mon 21 Nov 2016 04:34:38 PM UTC
bind-utils-9.8.2-0.47.rc1.51.amzn1.x86_64     Mon 21 Nov 2016 04:34:38 PM UTC
bind-libs-9.8.2-0.47.rc1.51.amzn1.x86_64      Mon 21 Nov 2016 04:34:38 PM UTC
openssh-6.6.1p1-31.62.amzn1.x86_64            Mon 21 Nov 2016 04:34:37 PM UTC
...

Относительно обновления openssh: https://alas.aws.amazon.com/ALAS-2016-770.html

Было обнаружено, что демон sshd OpenSSH извлекал настройки среды PAM перед запуском программы входа в систему . В конфигурациях с UseLogin = yes и модулем PAM pam_env, настроенным для чтения параметров пользовательской среды, локальный пользователь может использовать эту уязвимость для выполнения произвольного кода от имени пользователя root.

/ etc / ssh / sshd_config имеет:

UsePAM yes
#UseLogin no
#PermitUserEnvironment no

Последние обновления кажутся как наиболее вероятный виновник. Есть ли проблема конфигурации, из-за которой только пользователи chroot внезапно перестают получать доступ к последней версии openssh?

7
задан 22 November 2016 в 16:48
2 ответа

Правка: Это должно быть зафиксировано в openssh-6.6.1p1-32.el7 в пересчете на https://bugzilla.redhat.com/show_bug.cgi?id=1398569

Появляется после обновления OpenSSH-6.6.1p1-31, при попытке подключения по протоколу SFTP проверяется на подлинность только первичная группа пользователя. Если корень и основная группа пользователя владеют домашним каталогом и, по крайней мере, 710 разрешениями, то попытки подключения должны быть успешными.

Шаги повторения:

$ groups sftpuser  
sftpuser : sftpgroup sftpuser  
$ ls -ld /home/sftpuser/  
drwx--x--- 2 root sftpuser 4096 Nov 22 18:31 sftpuser/  
$ sftp sftpuser@localhost  
sftpuser@localhost's password:  
Write failed: Broken pipe  
Couldn't read packet: Connection reset by peer  
$ chgrp sftpgroup sftpuser/  
$ ls -ld /home/sftpuser/  
drwx--x--- 2 root sftpgroup 4096 Nov 22 18:31 sftpuser/  
$ sftp sftpuser@localhost  
sftpuser@localhost's password:  
Connected to localhost.  
sftp> exit  
  

Неудачное соединение с домашней директорией, принадлежащей вторичной группе (из /var/log/secure):

sshd[31640]: Accepted password for sftpuser from 127.0.0.1 port 34380 ssh2
sshd[31640]: pam_unix(sshd:session): session opened for user sftpuser by (uid=0)
sshd[31640]: fatal: Unable to chdir to chroot path "/home/sftpuser": Permission denied [postauth]
sshd[31640]: pam_unix(sshd:session): session closed for user sftpuser
  
Удачное соединение с домашней директорией, принадлежащей первичной группе (из /var/log/secure):
sshd[31647]: Accepted password for sftpuser from 127.0.0.1 port 34382 ssh2
sshd[31647]: pam_unix(sshd:session): session opened for user sftpuser by (uid=0)
sshd[31647]: session opened for local user sftpuser from [127.0.0.1] [postauth]
sshd[31647]: session closed for local user sftpuser from [127.0.0.1] [postauth]
sshd[31647]: Received disconnect from 127.0.0.1: 11: disconnected by user [postauth]
sshd[31647]: pam_unix(sshd:session): session closed for user sftpuser
.
7
ответ дан 2 December 2019 в 23:37

Я отправил аналогичный вопрос после прочтения ответа от @Will. Я попробовал это решение, но не смог подобрать его для своего сценария.

Разрешения для chrooted пользователя не работают после обновления в Amazon Linux

Но это привело меня к решению - изменить основной GID для учетных записей пользователей, которые я привязал к GID группы, которую я использовал для создания разрешений в chrooted каталоге . Это сработало.

0
ответ дан 2 December 2019 в 23:37

Теги

Похожие вопросы