O usuário não pode fazer SFTP após o chroot

Question

Ubuntu 10.04.4 LTS

Estou tentando fazer o chroot do usuário 'sam'. De acordo com todos os artigos lá fora, isso deve funcionar, mas aparentemente eu ainda estou fazendo algo errado.

O usuário:

sam:x:1005:1006::/home/sam:/bin/false

Eu alterei / etc / ssh / sshd_config assim (na parte inferior do arquivo):

#Subsystem sftp /usr/lib/openssh/sftp-server
# CHROOT JAIL
Subsystem sftp internal-sftp
Match group users
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Eu adicionei sam ao grupo de usuários:

$groups sam
sam : sam users

Alterei as permissões para a pasta inicial do sam:

$ 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

Eu reiniciei o ssh e agora o sam não pode entrar com o SFTP. A sessão é criada, mas também fechada imediatamente:

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

O Cyberduck diz que Unexpected end of sftp stream. e outros clientes apresentam erros semelhantes.

O que eu esqueci / o que está errado?

Obrigado!

Editar

Eu não consegui fazê-lo funcionar, mesmo depois de entrar em contato com a lista de discussão do OpenSSH, então decidi redefinir todo o meu servidor (que era uma opção viável, felizmente). Está funcionando agora.

    

Answer 1

Mesmo que a resposta de jaume seja muito boa, isso não poderia me ajudar no final. Eu tentei a lista de discussão do OpenSSH, mas não tive sorte. Acabei de redefinir todo o meu servidor, o que eu ainda poderia fazer fortunatelly. Está funcionando perfeitamente agora.

    

Answer 2

Sua configuração definitivamente parece boa, vamos ver se podemos descobrir onde está o problema.

1. Verifique se a sua versão openSSH suporta ChrootDirectory :

   O suporte para a palavra-chave ChrootDirectory foi adicionado ao openSSH versão 4.8p1 ( link ). Verifique se pelo menos essa versão está instalada:

   dpkg --list openssh-server
   

   [Esta provavelmente não é a causa, de acordo com link versão do openssh-server é 5.3p1]

2. Teste o SFTP localmente.

   Digite um terminal no seu computador Ubuntu:

   sftp sam@localhost
   

   e veja se você pode efetuar login (você deve digitar a senha do sam quando perguntei). Se funcionar, pode haver um problema com o Cyberduck configuração.

   Se você não conseguir entrar, tente SFTP sem chroot.

3. Teste o SFTP localmente sem chroot.

   Prefixo isto:

   Match group users
       ChrootDirectory %h
       ForceCommand internal-sftp
       AllowTcpForwarding no
   

   com # para comentar, reinicie o sshd ( sudo service ssh restart ) e digite:

   sftp sam@localhost
   

   Digite a senha quando solicitado e veja se você pode efetuar login. pode efetuar login para solucionar a configuração chroot da seguinte maneira: tente passo 2 novamente com o comando sftp -vvv sam@localhost para verbose saída. Você também pode aumentar o nível de log de sshd adicionando LogLevel VERBOSE a /etc/ssh/sshd_config e reiniciando sshd . Esperançosamente você vê algo óbvio no console ou em /var/log/auth.log .

   Se você não conseguir fazer login, tente o SSH.

4. Teste o SSH localmente.

   O SFTP requer um SSH funcional, portanto, altere o shell do sam para / bin / bash:

   sudo usermod -s /bin/bash sam
   

   e tente:

   ssh sam@localhost
   

   Digite a senha de sam quando solicitado. Se você pode logar tente aumentar verbosidade como explicado em 3) para descobrir o que está errado ( sftp -vvv sam@localhost e LogLevel VERBOSE in /etc/ssh/sshd_config ). Outra possibilidade é que a inicialização da shell confunde a cliente sftp ( link ):

   2.9 - sftp/scp fails at connection, but ssh is OK.

   sftp and/or scp may fail at connection time if you have shell initialization (.profile, .bashrc, .cshrc, etc) which produces output for non-interactive sessions. This output confuses the sftp/scp client. You can verify if your shell is doing this by executing:

   ssh yourhost /usr/bin/true
   

   If the above command produces any output, then you need to modify your shell initialization.

   Se você não conseguir fazer login, tente ssh root@localhost . Se não funciona ou há algo errado com sshd no servidor. Aumentar verbosidade ( LogLevel VERBOSE in /etc/ssh/sshd_config ), reiniciar sshd e peruse /var/log/auth.log , a resposta provavelmente está lá.

Answer 3

Eu tive o mesmo problema, resolvido definindo o chroot-dir para raiz do proprietário e raiz do grupo.

chown root:root chroot-dir

    

Answer 4

Centos 7 - Eu tive o mesmo problema - tentei tudo sob o sol para diagnosticar - eventualmente mudei o subsistema sftp em '/ etc / ssh / sshd_conf', reiniciei o sshd ( service sshd restart ) e o problema foi corrigido :

De:

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

Para:

Subsystem sftp internal-sftp

Não tenho ideia de por que duas implementações são fornecidas

    

Answer 5

1. Para o erro "conexão recusada", marque a opção "UsePAM yes" em sshd_config. Deve ser ANTES de "subsistema sftp"

2. Para problemas de autenticação, verifique se o diretório EACH no caminho chroot pertence ao usuário root e se tem permissões 755 ou menos.

Exemplo: ChrootDirectory / var / www / data

Você precisa verificar as permissões e o proprietário de: / var, / var / www, / var / www / data

3. Para problemas estranhos, como "a conexão é encerrada após a autenticação", tente atualizar ou alterar o servidor SFTP.

apt-get instala o openssh-server

"Subsistema sftp interno-sftp" < - > "Subsistema sftp / usr / lib / openssh / sftp-server" (alterne do tipo com seus problemas para outro)