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
- Você não pode ter o usuário chamado 'home' com um diretório base
/home/home
- Você precisa ter cuidado com os scripts que atravessam
/home hierarchy e seguem symlinks.