Como criar um SFTP restrito no Linux Amazon EC2 com OpenSSH

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 [email protected]

E se o usuário tentar usar SSH para logar no servidor, será bloqueado:

ssh [email protected]
[email protected]'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

1. 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 ou se tiver outras dúvidas, deixe seu comentário abaixo!

Fernando Ulisses dos Santos

Mais artigos deste autor »

Empreendedor em Empresas de Tecnologia da Informação.

Pós-Graduado em Segurança da Informação, certificado VMware VCAP-DTD.

Atualmente trabalha no seu mais novo projeto, o Sky Monitor.

Idealizou e criou o PowerBiz, ferramenta para Convertion Rate Optimization em Marketing Digital.

Criou o Business Monitor, um mini sistema de BI para geração de Dashboards em tempo real.

Fundador da Blue Solutions, onde trabalhou em dezenas de projetos de virtualização, reestruturação, implantação e migração de Datacenter em empresas de todos os portes.


Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!