Muitas vezes precisamos liberar um espaço para transferência de arquivos em nossos servidores, mas considerando a insegurança do protocolo FTP uma das melhores alternativas é usar SFTP.
Depois da primeira autenticação (quando ocorre a troca de chave entre o servidor e o cliente), isso previne ataques de Man-In-The-Middle e todo o tráfego é criptografado entre as partes.
Mas o serviço de SFTP do OpenSSH permite por padrão que o usuário que acesse o mesmo tenha acesso a todos os diretórios do servidor, possa listar pastas de outras contas e até obter alguns arquivos do sistema, isso não é desejado.
É possível criar usuários com acesso restrito, ou seja, ele terá acesso apenas aos diretórios definidos, para isso precisamos fazer algumas configurações prévias:
1. Criar um grupo para os usuários com SFTP restrito
O objetivo de criar um grupo é para organizar os usuários, limitando todos os usuários que fizerem parte desse grupo, para não ter que ficar alterando a configuração geral do servidor SSH a cada novo usuário criado.
O comando para criar o grupo que será para os usuários com acesso restrito é:
sudo groupadd sftpgroup
Escolhemos o nome sftpgroup, mas pode ser qualquer nome válido de grupo do Linux, desde que ajuste as próximas configurações para o mesmo nome.
2. Configurar o serviço SFTP para restringir os acessos para o grupo criado
Adicionar ao arquivo /etc/ssh/sshd_config:
# Aplica a configuração para os usuários do nosso grupo criado Match Group sftpgroup # Permite autenticação via senha, o que por padrão é bloqueado no Amazon Linux (opcional) PasswordAuthentication yes # Força a conexão ao SFTP interno ForceCommand internal-sftp -l INFO # Limita o acesso do usuário apenas no diretório "home" dele ChrootDirectory %h # Bloqueia tunelamento, autenticação e shell comum: PermitTunnel no AllowAgentForwarding no AllowTcpForwarding no X11Forwarding no PermitTTY no
Reiniciar o serviço sshd para que as alterações façam efeito:
sudo systemctl restart sshd
3. Criar o usuário
Agora precisamos criar o usuário atribuindo o mesmo ao grupo de SFTP restrito, observe também que restringimos o login dele, caso a configuração do OpenSSH não esteja correta, isso bloqueará o acesso:
sudo useradd -g sftpgroup usuariorestrito -s /sbin/nologin sudo passwd usuariorestrito
Será criado um diretório para o usuário em /home/usuariorestrito, mas esse diretório precisa de ajustes de permissões para funcionar de forma restrita:
chown root.root /home/usuariorestrito chmod 755 /home/usuariorestrito
4. Criar diretório de dados
Como o home do usuário recebeu permissões do usuário root, o usuário em si não terá permissões para criar pastas ou arquivos, então vamos criar uma pasta para ele subir os dados:
mkdir -p /home/usuariorestrito/dados chown usuariorestrito.sftpgroup /home/usuariorestrito/dados
Muitos provedores preferem criar os diretório public_html e public_ftp para indicar onde devem ir os dados que serão publicados, se for seu caso, pode criar sem problemas.
4.1. Opcional: criar um novo home pro usuário
Acontece que por padrão o usuário não logará no diretório de dados e pode tentar subir arquivos na raiz e obter mensagens de erro que não tem permissão.
Para resolver isso, podemos criar um novo home pra ele e ele automaticamente entrará nesse diretório:
mkdir -p /home/usuariorestrito/home/usuariorestrito chown usuariorestrito.sftpgroup /home/usuariorestrito/home/usuariorestrito
Quando o usuário logar, ele automaticamente entrará nesse diretório e já terá permissões para subir arquivos e criar pastas, é um pouco estranho, mas pode evitar alguns chamados no suporte.
5. Testar a conexão
A partir de outro servidor, testar o acesso:
sftp usuariorestrito@servidor.destino
E se o usuário tentar usar SSH para logar no servidor, será bloqueado:
ssh usuariorestrito@servidor.destino usuariorestrito@servidor.destino's password: PTY allocation request failed on channel 0 This service allows sftp connections only. Connection to servidor.destino closed.
6. Logar via chave de autenticação
Para automatizar scripts ou mesmo para oferecer maior segurança, a autenticação via chave é melhor.
Caso queira logar via chave de autenticação ao invés de senha, basta subir o arquivo da chave pública em:
/home/usuariorestrito/.ssh/authorized_keys
O próprio usuário pode criar o diretório “.ssh” e subir a chave com o nome “authorized_keys”, a única observação é cuidar das permissões, que devem ser 700 para o diretório (no máximo 755) e 600 para o arquivo (no máximo 640).
7. Criar registros de Auditoria
Também podemos registrar todos os comandos executados pelo cliente, como arquivos que ele fez upload, download, moveu ou apagou, para isso:
cd /home/usuariorestrito sudo mkdir dev sudo touch dev/log sudo chmod 511 dev/log sudo chattr +i dev/log sudo mount --bind /dev/log /home/usuariorestrito/dev/log
No arquivo /etc/rsyslog.conf, adicionar as linhas:
:programname, isequal, "internal-sftp" -/var/log/sftp.log :programname, isequal, "internal-sftp" ~
E reiniciar o serviço:
sudo systemctl restart rsyslog
Isso fará com que todos os comandos executados (upload e download de arquivos) sejam logados no arquivo /var/log/sftp.log.
Resolução de Problemas:
- Mensagem de erro no /var/log/secure:
fatal: bad ownership or modes for chroot directory
O diretório home do usuário precisa de permissões de usuário root e grupo root para funcionar como um diretório restrito, veja o segundo grupo de comandos no item 3 acima.
2. Não consigo criar arquivos:
Veja o item 4 acima, é preciso criar um diretório de dados e dar permissão para o usuário.
3. Mensagem de erro no /var/log/secure:
error: AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys usuariorestrito SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx failed, status 22
Esse erro normalmente acontece em servidores com Amazon Linux, eles configuram para invocar o script eic_run_authorized_keys para autenticar via chave, até onde investiguei, essa mensagem ocorre por um erro de permissão.
Não deve afetar nosso logon via chave nem logon via senha.
Eu consegui omitir esse erro comentando as seguintes linhas no /etc/ssh/sshd_config:
# AuthorizedKeysCommand /opt/aws/bin/eic_run_authorized_keys %u %f # AuthorizedKeysCommandUser ec2-instance-connect
E reiniciando o serviço sshd.
Mas pelo que vi, esse script permite autenticação de usuários do IAM, então, ao comentar essas linhas, você pode acabar quebrando outras funcionalidades, melhor não mexer.
Se você souber o que significa esse erro e como resolver, deixe nos comentários.
