Falha repentina de SFTP para contas chroot no Amazon Linux

Question

Frustrantemente, os usuários de SFTP de repente pararam de se conectar ao meu servidor Amazon Linux.

O / var / log / secure mostra o seguinte erro:

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

Saída de depuração do 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

O SELinux está desativado:

$ 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

Não houve alterações de configuração nem alterações de permissões, mas a atualização do yum foi executada ontem:

$ 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
...

Em relação à atualização do openssh: link

It was discovered that the OpenSSH sshd daemon fetched PAM environment settings before running the login program. In configurations with UseLogin=yes and the pam_env PAM module configured to read user environment settings, a local user could use this flaw to execute arbitrary code as root.

/ etc / ssh / sshd_config possui:

UsePAM yes
#UseLogin no
#PermitUserEnvironment no

As últimas atualizações parecem ser o culpado mais provável. Existe um problema de configuração que faria com que apenas os usuários chroot interrompessem o acesso negado com o último openssh?

    

Answer 1

Edit: Isto deve ser corrigido em openssh-6.6.1p1-32.el7 por link

Aparece após a atualização do OpenSSH-6.6.1p1-31, somente o grupo primário do usuário é verificado para autenticação durante a tentativa de conexão do SFTP. Com raiz e o grupo principal do usuário que possui o diretório inicial e pelo menos 710 permissões, as tentativas de conexão devem ser bem-sucedidas.

Passos do Repro:

$ 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  
  

Falha na conexão com o grupo secundário que possui o diretório inicial (em / 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
  

Conexão bem-sucedida com o diretório principal que possui o diretório inicial (de / 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

    

Answer 2

Eu postei uma pergunta semelhante depois de ler a resposta da @Will. Eu tentei essa solução, mas não consegui acertar para o meu cenário.

Permissões no usuário do chrooted que não está funcionando após atualização no Amazon Linux

Mas isso me levou à solução - alterar o GID primário para as contas de usuário que fiz chrooted para o GID do grupo que usei para criar permissões no diretório chrooted. Funcionou.