Início / unix / Perguntas / 786978
Accepted
user1169587
Asked: 2024-11-21 13:10:35 +0800 CST

como fazer o login sftp em um diretório específico

  • 772
  1. Eu sigo o tutorial em https://www.cybrosys.com/blog/how-to-setup-sftp-server-on-ubuntu-20-04

e eu consigo logar com sucesso no sftp, mas depois do logar, a pasta padrão é "/", e não consigo criar pasta em "/". O que eu quero é que quando o usuário logar no sftp, a pasta padrão seja o diretório home do usuário, como "/home/sftp_user" e consiga criar pasta em "/home/sftp_user"

o /etc/ssh/sshd_config é o seguinte:

Subsystem       sftp    internal-sftp

Match group sftp
ChrootDirectory /home
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

o direito de acesso no diretório /home é o seguinte:

drwxr-xr-x  4 root      root 4096 Nov 19 17:59 .
drwxr-xr-x 20 root      root 4096 Oct 30  2023 ..
drwxr-x--- 35 abc       abc  4096 Nov 20 18:28 abc
drwxrwxrwx  8 sftp_user sftp 4096 Nov 20 18:32 sftp_user

Se eu alterar ChrootDirectory /home para %h, então quando efetuar login sftp [email protected]

ele retorna "client_loop: send disconnect: Broken pipe". Eu pesquisei no Google e disse que o ChrootDirectory deve ser de propriedade do root e não pode ser escrito por outros. Mas se ele não pode ser escrito por outros, como posso criar um diretório no ChrootDirectory?

  1. no tutorial https://www.cybrosys.com/blog/how-to-setup-sftp-server-on-ubuntu-20-04 ,
    o subsistema é

    Subsystem sftp /usr/lib/openssh/sftp-server

mas vejo muitos outros tutoriais, o subsistema é

Subsystem       sftp    internal-sftp

o que devo usar?

sftp

2 respostas

  1. A informação que você pesquisou no Google chrootera para o comando, e não para a configuração no arquivo sshd_config. Ela não se aplica às configurações SFTP que você está tentando usar.

    O parâmetro do arquivo sshd_config ChrootDirectory %hestá correto.

    • O usuário deve existir no sistema de autenticação (para você, provavelmente é a autenticação local usando os arquivos /etc/passwd e /etc/shadow).
    • O campo do diretório home do usuário na entrada /etc/passwd não deve estar vazio, e esse diretório home deve ter sido criado no sistema de arquivos. O diretório home em si deve ser de propriedade do usuário e do grupo primário do usuário (o uid e o gid na entrada /etc/passwd), com permissões 0711 ou 0755. Minha preferência é 0711.
    • Os diretórios pais acima do diretório inicial do usuário SFTP geralmente são de propriedade do root, gid root, com permissões 0755.
    • O diretório .ssh sob o diretório home do usuário tem o mesmo proprietário/grupo que o diretório home, com permissões 0700. Arquivos no diretório .ssh devem ter permissões 0600. Alguns arquivos podem ter permissões um pouco mais abertas, 0644 ou 0640, mas outros arquivos não devem ser legíveis por ninguém além do proprietário. Para mim, usar permissões 0600 para todos os arquivos funciona e é mais fácil de lembrar.

    Com essas configurações, seu usuário SFTP não poderá executar chdir fora do diretório home, mas poderá ler e gravar arquivos no diretório home. (pode criar e excluir subdiretórios no diretório home também). Isso significa que o usuário pode sobrescrever ou excluir/criar seu próprio arquivo authorized_keys no local padrão ( ~/.ssh/authorized_keys).

    Meus testes mostram que o usuário SFTP pode até mesmo excluir seu próprio diretório home. Se fizer isso, ele ficará preso - ele não poderá criar seu diretório home novamente (sem permissões de gravação no diretório pai), e sua próxima tentativa de login falhará por causa do diretório home ausente.

    Se você não quiser que o usuário manipule seu arquivo authorized_keys, você pode usar o AuthorizedKeysFile /path/to/authorizedkeys/%uparâmetro para colocar o arquivo em algum lugar fora do diretório home do usuário, onde ele não pode tocá-lo. Se você quiser, o arquivo em si deve ser de propriedade do usuário SFTP e seu grupo primário, com permissões 0600, e deve estar em um diretório com permissões 0711 ou 0755 (0711 preferencial), mas esse diretório pode ser de propriedade do root, grupo root. Os diretórios pais desse diretório devem ser de propriedade do root, grupo root com permissões 0755.

    O caminho no exemplo acima /path/to/authorizedkeys/%ué apenas um exemplo. O %upara o nome do arquivo significa que ele é o mesmo que o nome de usuário, o que ajuda a manter as chaves organizadas para vários usuários SFTP.

    Há algumas etapas de configuração adicionais se você quiser ter alguns usuários que só podem fazer SFTP e outros usuários que podem fazer logins interativos (como administradores de sistema). Não incluí essas etapas nesta resposta, mas posso, se você quiser.

    • 0
  2. Best Answer

    O motivo do comportamento que você está vendo é um bug/recurso ruim de longa data do ChrootDirectorysuporte OpenSSH. No entanto, ele tem uma solução alternativa fácil.

    Quando você especifica um ChrootDirectorypara um usuário (ou um grupo de usuários), as sessões SSH/SFTP às quais a configuração é aplicada verão o diretório especificado pela ChrootDirectorydiretiva como o diretório raiz ( /). Isso torna quaisquer arquivos que não estejam no ChrootDirectory ou seus subdiretórios inacessíveis para essas sessões: não haverá como construir um nome de caminho que se refira a tais arquivos.

    O bug/má característica é que, quando o OpenSSH está aplicando a ChrootDirectorydiretiva, ele não fará uma alteração correspondente no caminho do diretório home do usuário que ele leu /etc/passwd. Como resultado, se ChrootDirectory /homeestiver em vigor para um usuário com diretório home /home/sftp_user, então sshdtentará encontrar /home/home/sftp_usero que obviamente não existe.

    A solução alternativa para isso é criar um link simbólico /home/homeapontando de volta para o diretório atual:

    cd /home
sudo ln -s . home  #yes, exactly like this

    Depois disso, o caminho do diretório inicial /home/sftp_userserá aplicável tanto dentro quanto fora do chroot, e o chrooted sftp_userverá um diretório inicial gravável como /home/sftp_user-> /./sftp_user== /sftp_user.

    O tutorial que você está usando tem a linha de configuração do subsistema SFTP como

    Subsystem      sftp    /usr/lib/openssh/sftp-server

    Isso não funciona quando ChrootDirectory /homeestá em vigor, pois /usrnão está em vigor /homee, portanto, ficará inacessível.

    O tutorial contorna isso usando ForceCommand internal-sftp.

    Por enquanto, ambas as formas parecem funcionar, mas uma atualização futura do OpenSSH pode tornar os logins do subsistema mais rigorosos e fazer com que o login falhe se o subsistema especificado não estiver realmente disponível, antes que o ForceCommand entre em vigor. Eu consideraria o Subsystem sftp internal-sftpcomo um pouco mais robusto e à prova do futuro.

    • 0

relate perguntas