Como restringir usuários SSH a diretórios específicos no Ubuntu 24.04 (Guia de Chroot SFTP)

Conceder a um contratado acesso para fazer upload de alguns arquivos não deve automaticamente dar a essa pessoa uma sessão de terminal com visão de todo o servidor. No Ubuntu 24.04 LTS, o OpenSSH pode restringir uma conta de transferência de arquivos a um diretório escolhido usando uma ChrootDirectoryregra e o servidor integrado internal-sftp. A distinção importante é que essa é uma restrição exclusiva para SFTP , e não uma maneira simples de fornecer um shell Bash totalmente funcional, porém restrito.

Este guia explica o que as configurações realmente protegem e, em seguida, descreve uma configuração reversível em oito etapas para várias contas, cada uma com seu próprio diretório. Os comandos usam uma conta de exemplo chamada `user` contractore um host de exemplo chamado `host` server.example.com; substitua-os pelos seus próprios valores. Estes são exemplos de configuração e não resultados obtidos em um teste de servidor real.

De que tipo de restrição você realmente precisa?

Três controles são frequentemente confundidos. As permissões do Linux definem quais arquivos uma conta pode ler ou modificar; alterar o diretório home da conta define um local inicial; um chroot altera a raiz do sistema de arquivos apresentada a um processo. Eles não são intercambiáveis.

Conceito errado: definir /home/contractoro diretório inicial confina o usuário a ele. Não confina. Um usuário comum do shell pode navegar para qualquer diretório acessível em qualquer lugar do sistema de arquivos. Se a troca de arquivos for realmente necessária, escolha a rota somente SFTP descrita abaixo, em vez de tentar ocultar diretórios com o prompt do shell.

Documentos do OpenSSH ChrootDirectory, Matche ForceCommandno manual oficial do Ubuntu 24.04 sshd_config .

Configure um diretório isolado somente com SFTP em oito etapas.

Antes de modificar o SSH remotamente, mantenha sua sessão de administrador aberta e certifique-se de ter acesso ao console ou ao modo de recuperação. Use uma conta separada sem privilégios para transferências; não adicione sua conta de administrador ao grupo restrito.

1. Verifique o OpenSSH e mantenha uma sessão de recuperação.

No servidor, instale o OpenSSH, se necessário, verifique o serviço e salve a configuração principal. A documentação oficial do Ubuntu para servidores oferece suporte a esses caminhos de serviço e configuração.

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.pre-sftp

Se você só puder administrar a máquina via SSH, não feche a sessão atual enquanto estiver editando ou testando. Consulte o guia de configuração do servidor OpenSSH do Ubuntu antes de alterar o daemon.

2. Crie um grupo de acesso dedicado para usuários e SFTP.

Um grupo é útil quando você espera mais de uma conta restrita. Este exemplo atribui a cada membro uma área restrita separada usando o %utoken, que o OpenSSH expande para o nome de usuário de conexão. O /uploadcaminho inicial deve existir dentro do futuro ambiente chroot, portanto, não crie um /uploaddiretório no nível do host.

sudo groupadd sftpclients
sudo adduser --home /upload --no-create-home --shell /usr/sbin/nologin contractor
sudo usermod -aG sftpclients contractor
id contractor

O adduserfluxo pode solicitar que você defina uma senha. Em instalações que desabilitam a autenticação por senha SSH, crie e autorize uma chave pública; não habilite logins com senha globalmente apenas para seguir um exemplo. O nologinshell é outra medida de segurança, mas o comando imposto internal-sftpé o que torna essa configuração transferível. Teste a combinação em sua própria infraestrutura de autenticação.

3. Crie um diretório chroot pertencente ao root.

É aqui que muitos guias erram. O OpenSSH exige que todos os componentes do caminho chroot pertençam ao usuário root e não sejam graváveis ​​por outros usuários ou grupos. Nunca torne o próprio diretório raiz do jail gravável pela conta SFTP.

sudo install -d -o root -g root -m 0755 /srv/sftp
sudo install -d -o root -g root -m 0755 /srv/sftp/contractor
namei -l /srv/sftp/contractor

Verifique também os componentes existentes /; /srvos comandos acima não corrigem automaticamente permissões inseguras do componente pai. Se algum componente for gravável pelo grupo ou pertencer ao usuário, corrija sua propriedade e modo somente após verificar se outros aplicativos dependem dele.

4. Adicione um subdiretório gravável dentro da jail.

A conta pode escrever em um subdiretório sem ter permissão para alterar o diretório raiz chroot. Crie um diretório /srv/sftp/contractor/uploadpara os arquivos reais da conta; de dentro do SFTP, ele aparecerá como /upload.

sudo install -d -o contractor -g contractor -m 0750 /srv/sftp/contractor/upload
sudo stat -c '%U:%G %a %n' /srv/sftp/contractor /srv/sftp/contractor/upload

A propriedade esperada difere deliberadamente: root:rootpara a raiz da jail e contractor:contractorpara a pasta de upload gravável. Evite usar `<username>` chmod 777, que introduziria exposição desnecessária e seria rejeitado se aplicado à raiz da jail.

5. Adicione uma regra de correspondência ao sshd_config.

Abra /etc/ssh/sshd_confige adicione o seguinte bloco ao final, após quaisquer diretivas e Matchblocos existentes. Use um editor de texto como o iframe sudoeditou o dpkg sudo nano. Revise as regras existentes Matchprimeiro: se vários blocos correspondentes atribuírem a mesma palavra-chave, o OpenSSH usará a primeira instância aplicável. O Ubuntu também processa arquivos em /etc/ssh/ssh/ssh.conf /etc/ssh/sshd_config.d/a partir de uma versão anterior Include; as regras ali presentes podem afetar a precedência.

Match Group sftpclients
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /upload
    PermitTTY no
    DisableForwarding yes

Match Grouptem como alvo membros de sftpclients. ChrootDirectorycoloca cada usuário em /srv/sftp/USERNAME. ForceCommand internal-sftp -d /uploadexecuta um serviço SFTP em processo e inicia dentro do diretório gravável. PermitTTY noimpede a alocação de terminal, enquanto DisableForwarding yesdesativa os recursos de encaminhamento SSH para conexões correspondentes.

Mantenha a Subsystem sftpdiretiva global já fornecida pelo Ubuntu, a menos que você tenha um motivo específico para alterá-la; o comando SFTP interno forçado não exige a substituição dessa linha global. Não adicione uma diretiva global extra Match Allapenas para finalizar um bloco sem entender o impacto que isso terá.

6. Verifique a sintaxe e as configurações efetivas antes de recarregar.

A análise bem-sucedida não comprova que as permissões da prisão estejam corretas, nem que a conta pretendida esteja em conformidade com a política. Realize ambas as verificações explicitamente.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=contractor,host=localhost,addr=192.0.2.10 | grep -E '^(chrootdirectory|forcecommand|permittty|disableforwarding) '
namei -l /srv/sftp/contractor

A configuração efetiva deve identificar o caminho chroot pretendido, o comando SFTP forçado, a alocação de TTY desativada e as restrições de encaminhamento. O endereço de exemplo 192.0.2.10é apenas para fins de documentação; se você tiver Matchregras dependentes de endereço, substitua-o pelo endereço de origem real do cliente. O -T -Cformato está documentado no manual do sshd do Ubuntu 24.04 .

Se a validação falhar, corrija a configuração antes de recarregar o SSH. Se os valores efetivos forem inesperados, inspecione os trechos incluídos e a ordem dos blocos condicionais existentes, não apenas as últimas linhas que você editou.

7. Recarregue o SSH e preserve seu acesso de administrador.

Após as verificações bem-sucedidas, reinicie o serviço SSH para que as novas conexões usem a política editada. Mantenha a conexão de administrador atual ativa enquanto abre um segundo terminal para confirmar se o acesso normal de administrador ainda funciona.

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

Uma reinicialização completa também pode aplicar alterações, mas uma recarga é preferível quando suportada e para evitar interrupções desnecessárias. A saída do comando de serviço e as mensagens de log variam de acordo com o host, portanto, inspecione o resultado real em vez de presumir que um retorno bem-sucedido ao prompt garante o acesso.

8. Teste as transferências permitidas e o acesso bloqueado ao shell.

A partir de outro computador, conecte-se como o usuário restrito. Use o nome de host real do servidor e um arquivo de teste adequado. O primeiro diretório SFTP deve ser /upload, e o diretório raiz do chroot deve aparecer como /em vez do caminho do host /srv/sftp/contractor.

sftp contractor@server.example.com
sftp> pwd
sftp> cd /
sftp> ls
sftp> cd /upload
sftp> put sample.txt
sftp> cd /etc
sftp> exit

O envio de um arquivo de teste inofensivo deve ser permitido /upload. O acesso ao diretório raiz real do host /etcnão deve ser possível: o chroot define uma raiz diferente, que /etcsó seria acessível se você criasse ou expusesse deliberadamente esse diretório dentro do ambiente isolado (jail). A mensagem de erro exata do cliente não é importante.

ssh contractor@server.example.com

Não deve ser possível abrir um shell SSH interativo comum para esta conta. Em vez disso, a conexão pode ser fechada ou exibir uma mensagem relacionada ao protocolo; não confie em uma frase exata. Se um shell for aberto, considere a configuração como insegura e revise a associação ao grupo, Matcha precedência e sshd -T -Ca saída efetiva antes de usar a conta.

E se você usar chaves públicas SSH?

A autenticação por chave pública funciona com um ambiente SFTP isolado, mas definir o diretório home do usuário no nível do host /uploadsignifica que o caminho padrão ~/.ssh/authorized_keyspode não existir fora do ambiente isolado. Uma alternativa prática é permitir que o SSH leia um arquivo de chave controlado pelo root antes de iniciar o chroot. Adicione o seguinte dentro do mesmo Match Group sftpclientsbloco se você optar pelo armazenamento centralizado de chaves:

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Em seguida, crie um /etc/ssh/authorized_keys/contractorarquivo contendo a chave pública autorizada do contratado, com propriedade root e sem permissões de gravação para o grupo ou para todos os usuários. Por exemplo, após copiar com segurança um arquivo de chave pública verificado contractor.pubpara um diretório de preparação administrativo:

sudo install -d -o root -g root -m 0755 /etc/ssh/authorized_keys
sudo install -o root -g root -m 0644 contractor.pub /etc/ssh/authorized_keys/contractor
sudo /usr/sbin/sshd -t

Não copie a chave privada para o servidor. A configuração do caminho da chave, os padrões de autenticação e as verificações de conta dependem da sua política SSH existente; verifique o acesso por chave pública antes de desativar um método de autenticação que já esteja funcionando.

Falhas comuns e seus significados

Verifique os logs com sudo journalctl -u ssh -n 80 --no-pager. O erro exato depende das configurações PAM, da configuração SSH, do acesso ao sistema de arquivos e do método de autenticação. O OpenSSH 9.0 e versões mais recentes usam SFTP para scptransferências padrão por padrão, enquanto o modo legado requer um shell, conforme explicado no manual do scp do Ubuntu 24.04 .

É possível restringir um shell SSH interativo a uma única pasta?

Não com uma simples alteração no diretório home ou com o exemplo acima, que usa apenas SFTP. O OpenSSH ChrootDirectorytambém pode ser usado para sessões de shell, mas o ambiente de segurança (jail) deve incluir um shell funcional, suas bibliotecas compartilhadas, os nós de dispositivo necessários e quaisquer dependências de comando. Criar esse ambiente com segurança exige mais do que definir uma única linha no arquivo de configuração sshd_config. É fácil criar uma configuração frágil ou enganosa, especialmente quando comandos de shell arbitrários ou montagens estão envolvidos.

Se um usuário realmente precisa de comandos interativos, especifique primeiro exatamente quais comandos e arquivos ele requer. Para um conjunto pequeno de comandos, use comandos remotos com escopo restrito ou um endpoint de aplicativo dedicado. Para ambientes independentes mais amplos, considere um contêiner ou máquina virtual com montagens de sistema de arquivos explícitas, controles de privilégios e restrições de rede. Um chroot por si só não substitui o isolamento completo do sistema, e nem o chroot nem as permissões de arquivo do Unix protegem contra um usuário privilegiado que possa alterar o sistema subjacente.

Lista de verificação de segurança antes de conceder acesso.

• A conta de transferência não é de administrador e pertence apenas aos grupos necessários.
• Cada componente que leva à prisão pertence ao root e não possui permissão de escrita para o grupo ou para todos os usuários.
• O local de upload gravável está dentro da jail, não na raiz da jail em si.
• O usuário pretendido corresponde a ChrootDirectory, ForceCommand internal-sftp, e o encaminhamento foi desativado na configuração efetiva.
• Um upload SFTP real é bem-sucedido, uma tentativa de acessar arquivos restritos ao host falha e o acesso normal ao shell SSH é bloqueado.
• O backup, a retenção, as quotas, o monitoramento e a revogação de contas são gerenciados separadamente; um diretório isolado não implementa essas políticas automaticamente.

Para obter detalhes mais técnicos, consulte a referência de configuração do OpenSSH no Ubuntu 24.04 e o manual do servidor SFTP do Ubuntu . Estas instruções são direcionadas ao Ubuntu 24.04 LTS; versões de pacotes e trechos de código SSH existentes podem alterar o comportamento, portanto, a decisão final cabe à configuração e aos testes de conexão reais em seu próprio host.