CHROOT: Não é possível copiar arquivos para o diretório de usuários presos da máquina local usando o WINSCP

Question

Eu configurei um ambiente chroot para um dos meus usuários chamado client no meu sistema. Eu estou usando o WINSCP para se conectar ao meu servidor da minha máquina usando a autenticação de chave pública. Tudo funciona bem, eu consigo acessar, ver o diretório pessoal (diretório de prisão) e não consigo navegar para cima.

O problema que estou tendo no momento é que não posso copiar arquivos para o servidor da minha máquina local. Quando faço isso, estou recebendo Permissão negada: Não é possível criar o arquivo remoto /home/client/test.txt

Meu servidor é um servidor Red Hat e esta é minha configuração sshd:

    Match User client
    ChrootDirectory %h
    PubkeyAuthentication yes
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

Procurei on-line para isso e encontrei algumas observações sobre como fazer cópias da pasta bin e lib no diretório pessoal do cliente, mas essas soluções não ajudaram.

Tudo o que preciso no momento é que o usuário possa copiar arquivos de sua máquina local para o meu servidor na pasta chroot.

EDIT # 1

Aqui está uma descrição rápida do que fiz:

Eu tenho um usuário chrooted (username: clientd) que eu prendi dentro de seu diretório home. Este diretório chroot é /home/client/ , que é de propriedade de root.

Agora eu preciso que esse usuário cliente possa acessar a pasta do aplicativo web tomcat que está em /mnt/datadrive/tomcat/webapps .

O que eu fiz é:

1. chroot o usuário com uma chave pública própria no diretório inicial.
2. Crie uma pasta em /home/client , chamada tomcat_ROOT , e atribua a propriedade a clientdev .

Agora, quando eu executo o comando:

$ mount --bind /mnt/datadrive/tomcat/webapps /home/client/tomcat_ROOT

A pasta desaparece da lista de diretórios dentro de /home/client se eu fizer o login com o cliente. Meu usuário root pode ver, mas não o usuário desejado.

Aqui estão algumas listagens de permissões:

Saída de ls -l /home/client/tomcat_ROOT :

drwxr-xr-x.  6 root   root    4096 Apr 11 15:07 .   
drwxrwxr-x. 12 root   root    4096 Apr 11 15:07 .. 
drwxr-xr-x.  3 root   root    4096 Apr  9 22:10 webapp1 
drwxr-xr-x.  4 root   root    4096 Mar 18 18:43 webapp2 
drwxr-xr-x.  3 root   root    4096 Apr  9 22:11 webapp3 
drwxrwxr-x. 10 root   root    4096 Apr 11 15:20 ROOT

Saída de ls -l /home/client/ :

drwx------. 4 clientdev clientdev 4096 Apr 10 21:36 . 
drwxr-xr-x. 7 root      root      4096 Apr 10 22:07 .. 
-rw-------. 1 client client  664 Apr 10 21:43 .bash_history 
-rw-r--r--. 1 client client   18 Apr 23  2012 .bash_logout 
-rw-r--r--. 1 client client  176 Apr 23  2012 .bash_profile 
-rw-r--r--. 1 client client  124 Apr 23  2012 .bashrc 
drwx------. 2 client client 4096 Apr 10 19:20 .ssh
drwxr-xr-x. 2 client client 4096 Apr 10 21:34 tomcat_ROOT

    

Answer 1

Eu tenho uma configuração parecida e funciona, então sua configuração parece válida para mim. Sugiro adicionar essa linha acima da regra de correspondência, o que permitirá um pouco mais de mensagens detalhadas em seus registros, o que pode ajudar você a restringir o foco no problema subjacente.

Subsystem   sftp    internal-sftp -f AUTH -l INFO

Certifique-se de reiniciar sshd após a alteração. Acredito que o seu problema tenha a ver com as permissões do diretório ou da pasta do usuário. Ao usar ChrootDirectory , existem algumas condições muito específicas que você deve ter certeza de aderir, caso contrário, o SSHD não cooperará.

 ChrootDirectory
        Specifies the pathname of a directory to chroot(2) to after 
        authentication.  All components of the pathname must be root-owned 
        directories that are not writable by any other user or group.  
        After the chroot, sshd(8) changes the working directory to the 
        user's home directory.

        The pathname may contain the following tokens that are expanded at 
        runtime once the connecting user has been authenticated: %% is 
        replaced by a literal '%', %h is replaced by the home directory of 
        the user being authenticated, and %u is replaced by the username of 
        that user.

        The ChrootDirectory must contain the necessary files and directories 
        to support the user's session.  For an interactive session this 
        requires at least a shell, typically sh(1), and basic /dev nodes 
        such as null(4), zero(4), stdin(4), stdout(4), stderr(4), arandom(4) 
        and tty(4) devices.  For file transfer sessions using “sftp”, no 
        additional configuration of the environment is necessary if the in-
        process sftp server is used, though sessions which use logging do 
        require /dev/log inside the chroot directory (see sftp-server(8) for 
        details).

        The default is not to chroot(2).

    

Answer 2

Por favor, verifique as permissões do diretório.

como se tivéssemos estrutura de pastas / home / test / app

que / home / test deve ter - 'chmod 700' e 'chown testuser test' e / home / test / app deve ter - 'chmod 750' e 'chown testuser app -R'

Por favor, tente

chmod 700 /home/client/
chown clientd /home/client/
cd /home/client/
chmod 750 * -R
chown clientd clientdev * -R

Também me avise se as permissões do diretório não forem alteradas.