Permissões de gravação do usuário SFTP com o cromador

9

Eu tenho uma configuração com apenas usuários do sftp:

Match Group sftponly
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

Eu recebo a seguinte mensagem no meu secure.log:

fatal: bad ownership or modes for chroot directory

Com a palavra-chave match, vem alguma coisa de segurança com ela ... os diretórios precisam ser de propriedade de root, e os diretórios precisam ser chmod 755 (drwxr-xr-x). Assim, torna-se impossível para um usuário ter permissões de gravação para as pastas, se for apenas gravável para o usuário root e definido como ben não-gravável para grupos devido à segurança do ssh.

Alguém sabe sobre um bom trabalho?

    
por Adionditsak 31.07.2014 / 16:39

5 respostas

2

Eu tenho as mesmas configurações no nosso servidor. Nós usamos a mesma configuração do SSHD. Os diretórios iniciais dos usuários são de propriedade de root e, dentro deles, há pastas documents e public_html pertencentes aos respectivos usuários. Os usuários então fazem o login usando SFTP e escrevem nessas pastas (não diretamente em casa). Como o SSH não é permitido para eles, funciona perfeitamente. Você pode ajustar quais diretórios serão criados para novos usuários em / etc / skel / (pelo menos no openSUSE, eu não estou tão familiarizado com outras distros).

Outra possibilidade seria ACL ( Documentação do openSUSE - pode adicionar permissão de gravação para o respectivo usuário para o seu diretório pessoal.

    
por 31.07.2014 / 17:40
7

Encontramos recentemente uma solução alternativa que funciona assim:

/ etc / ssh / sshd_config:

...

Subsystem sftp internal-sftp

Match Group sftponly
    ChrootDirectory /home
    AllowTCPForwarding no
    X11Forwarding no
    ForceCommand internal-sftp

permissões de diretório:

root@server:~ # chown root:root /home
root@server:~ # chmod 111 /home
root@server:~ # chmod 700 /home/*

Agora, /home satisfaz os requisitos de ChrootDirectory e não pode ser listado por usuários restritos, mas sftponly usuários não poderão efetuar login se seus diretórios pessoais estiverem configurados normalmente ( /home/$LOGNAME ) : sob o ambiente chrooted, seus diretórios home não estão dentro de /home , mas diretamente sob a raiz ( / ).

solução 1

Defina as residências dos usuários restritos como elas aparecem no chroot:

root@server:~ # usermod -d /username username

caveate 1

Se qualquer um dos usuários irrestritos ou algum script de administração usar a expansão til do bash como ~username , ele será expandido para /username agora, o que não é o que se entende.

Além disso, o administrador que cria sftponly usuários precisa se lembrar de usar a página inicial não padrão. Solveable com um script. Qual o administrador tem que lembrar de usar.

solução 2

Esta é uma alternativa à anterior que acabamos usando:

root@server:~ # ln -s . /home/home

Isso é criar um symlink dentro de /home para seu próprio dirname. Agora, sob chroot /home/username aponta para o mesmo diretório sem chroot. Para o usuário restrito logado com o sftp, ele aparecerá como /username . Este diretório é gravável para seu proprietário (usuário restrito). Usuário restrito não pode listar seus diretórios pai ou pai de qualquer um dos irmãos pelo nome.

A única coisa especial sobre um usuário sftponly é sua participação no grupo sftponly . Achamos mais fácil lidar do que a solução 1.

caveates 2

  1. Você não pode ter o usuário chamado 'home' com um diretório base /home/home
  2. Você precisa ter cuidado com os scripts que atravessam /home hierarchy e seguem symlinks.
por 10.10.2014 / 22:24
4

Você precisa criar uma estrutura dentro do diretório pessoal do usuário, como diretórios in e out. Esses diretórios devem ser de propriedade do usuário e ele poderá colocar e obter arquivos.

    
por 31.07.2014 / 17:39
0

Você deve criar a seguinte estrutura de diretório:

/ home / user

/ home / user / home / user < - o diretório real que o usuário terá acesso

Opcionalmente:

/home/user/.ssh/authorized_keys < - se você quiser autenticar com uma chave pública

    
por 09.02.2018 / 22:25
0

Em referência à seção 'permissões do diretório' na resposta do @artm (que acabei de testar) .. Eu encontrei:

root@server:~ # chmod 111 /home <- Does not work

Ele não permite que a conexão sftp funcione no Ubuntu com permissões de execução somente em tudo, por exemplo, 111.

Eu descobri que:

root@server:~ # chmod 555 /home

Funciona com conexão ao sftp com as permissões Ler e Executar, ou seja, 555. Não tenho certeza se o debian vs outros tipos são diferentes, mas é isso que funciona no meu ubuntu.

    
por 20.02.2018 / 19:41