sftp dá permissão negada apenas quando chrooted?

Question

Eu configurei o sshd_conf na minha caixa de centos como abaixo:

Match group pilots
ChrootDirectory /home/pilots
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no

e o diretório / home / pilots assim:

# 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
# 

Se eu entrar como um usuário no grupo de pilotos SEM a Diretiva ChrootDirectory ativada, posso fazer um cd para a pasta / home / pilots (ou um subdiretório dela) e fazer um ls ou obter sem dificuldade. No entanto, se eu habilitar a diretiva ChrootDirectory, enquanto eu ainda puder me inserir, e puder cd para os dados, não posso fazer um ls ou entrar em nenhum dos diretórios. Tentando ls, por exemplo, dá um readdir remoto ("/"): Permissão negada erro, e tentando obter topLevel dá File "/ topLevel" não encontrado. Eu estava pensando que talvez eu não estivesse no diretório que eu estava esperando, mas a capacidade de fazer cd de dados pareceria indicar que o chroot funcionava como deveria.

olhando para o log de mensagens, vejo o seguinte quando o ls é negado:

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

Então, há um registro da negação. Ainda não me diz porquê.

O que eu posso estar fazendo errado?

Algumas notas potencialmente importantes:

• Os usuários em questão existem em um servidor LDAP remoto, acessado via sssd
• O controle de acesso deve ser por grupo, pois muitos usuários precisarão de acesso de leitura a essa mesma pasta. Assim, a raiz restante da propriedade.

Editar: Em uma investigação mais aprofundada, parece que isso está relacionado com o SELinux - fazer um echo 0 >/selinux/enforce corrige o problema, ainda que em um kludgy, matando uma formiga com uma espécie de marreta. Se possível, gostaria de saber a correção "adequada".

    

Answer 1

Encontrei a solução em esta página . Para resumir, depois de configurar o sftp de acordo com a configuração acima, os dois comandos a seguir precisavam ser executados para permitir o acesso com o SELinux ativado:

setsebool -P ssh_chroot_rw_homedirs on
restorecon -R /home/$USERNAME

Nesse caso, o segundo comando seria restorecon -R /home/pilots . Depois disso, o sftp funciona como esperado, mesmo quando chrooted, sem ter que desabilitar completamente o SELinux.

    

Answer 2

Deixando de fora a resposta de @ ibrewster (incluindo o recurso externo ele está vinculado a), aqui está o conjunto completo de instruções daquela página externa, com algumas informações adicionais para fazer esse trabalho com senha login e execução do SELinux.

Publicar novamente aqui, caso a página vinculada externamente desapareça no futuro.

Estas instruções aplicam-se ao RHEL7 e ao CentOS7 (e talvez a outras versões):

No sistema remoto:

Primeiro, adicione e configure a conta de usuário para ser chrooted:

Observe que o recurso externo usou um caminho diferente para sftp-server . Certifique-se de ter o caminho correto em seu sistema ou prepare-se para a dor. ;-) O caminho abaixo funciona para uma instalação mínima do 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

Embora eu tenha definido uma senha acima, usarei o login sem senha quando souber que a configuração funciona. Para frente ...

Supondo que você tenha SELinux ativado e impondo (você deve), emita esses comandos para torná-lo feliz:

setsebool -P ssh_chroot_rw_homedirs on
restorecon -R /home/$USERNAME

Agora, edite a configuração do sshd da seguinte forma:

[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

Finalmente, reinicie o sshd

[root@remote]# systemctl restart  sshd.service

No sistema do cliente

Primeiro, crie a mesma conta localmente.

[root@client]# useradd -m $USERNAME
[root@client]# passwd $USERNAME
[root@client]# su $USERNAME

Ok, agora vamos configurar nosso par de chaves RSA.

[$USERNAME@client]# ssh-keygen

Não consegui fazer com que o ssh-copy-id trabalhasse com a configuração do chroot acima, então criei manualmente o arquivo authorized_keys com o texto id_rsa.pub do meu cliente.

[$USERNAME@client]# cat .ssh/id_rsa.pub
---some key here---

Então, de volta ao sistema REMOTE,

[root@remote]# vi /home/$USERNAME/.ssh/authorized_keys
---past key from right above, then wq---

Não se esqueça de definir permissões neste arquivo:

[root@remote]# chown $USERNAME:sftpusers  /home/$USERNAME/.ssh/authorized_keys

Pronto para testar

Tudo deve estar no lugar agora. Do cliente:

[$USERNAME@client]# sftp $USERNAME@remote

Isso deve ajudá-lo. Se você for solicitado a fornecer uma senha (ainda não desativamos PasswordAuthentication no controle remoto), você tem um problema de configuração no sistema remoto. Analise seu / var / log / secure para detalhes.

Se você entrar sem precisar digitar uma senha, estará quase pronto.

De volta ao sistema remoto:

[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 --

Reinicie o sshd no sistema remoto:

[root@remote]# systemctl restart  sshd.service

Teste final do cliente

[$USERNAME@client]# sftp $USERNAME@remote
# in like Flynn?  yay!

Concluído

Você deve estar configurado para usar chroot sftp e login sem senha (com SELinux definido como obrigatório )