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.