FTP, FTPS ou SFTP no cPanel/DirectAdmin: Arquitetura Correta e Falhas Comuns

Esse incidente aparece com frequência em hospedagem gerenciada: a conta FTP adicional conecta no FileZilla via FTPS, mas falha em SFTP com “Permission denied”. A equipe costuma tratar como senha incorreta, mas a causa real é de arquitetura de autenticação, não de credencial.

Sintoma típico

Cliente tenta SFTP na porta 22 com usuário adicional e recebe:

Authentication failed.
Permission denied (publickey,password).

Mesmo com senha confirmada no painel.

Causa raiz técnica

SFTP é subsistema do SSH (sshd), então autenticação passa por:

• usuários reais do sistema (/etc/passwd);
• PAM/políticas de shell/chroot;
• regras de SSHD.

Já contas FTP adicionais em cPanel/DirectAdmin são usuários virtuais do serviço FTP (Pure-FTPd/ProFTPD), não usuários reais do Linux.

Resultado: o SSH não reconhece esse usuário virtual e recusa sessão.

Diagnóstico que uso em produção

1. validar se usuário é do sistema:

getent passwd usuarioftp || echo 'usuario virtual (não existe no sistema)'

1. validar logs SSH durante tentativa:

tail -f /var/log/secure
# ou
journalctl -u sshd -f

1. validar serviço FTP ativo e TLS:

systemctl status pure-ftpd
# ou proftpd

Solução correta para contas delegadas

Para contas adicionais, use FTPS explícito (porta 21) com TLS obrigatório.

Configuração no cliente:

• protocolo: FTP;
• host: ftp.dominio.com;
• porta: 21;
• criptografia: FTP explícito sobre TLS;
• usuário: conta FTP adicional do painel.

Esse modelo preserva segmentação por pasta e autenticação suportada pelo painel.

Quando usar SFTP

SFTP deve ser reservado para:

• usuário principal da hospedagem;
• usuários Linux reais com SSH autorizado;
• cenários em que auditoria SSH é exigida.

Se for necessário acesso SFTP granular para terceiros, o desenho correto é criar usuário de sistema controlado com chroot, não reaproveitar conta FTP virtual.

Quando arquivos "somem" no FTP em diretórios lotados

Outro incidente comum: cliente jura que arquivo desapareceu, mas ele existe no servidor. Em geral, o problema é truncamento de listagem no FTP.

Validação rápida:

ls
ls -la

Se via shell os arquivos aparecem e no FTP não, a limitação está na camada FTP (daemon, canal de dados, cliente ou filtro de arquivos ocultos).

Para diretórios com alta volumetria, prefira SFTP e, se necessário, gere índice por shell para auditoria:

ls -1 > lista.txt

Hardening recomendado

1. desativar FTP sem TLS;
2. restringir ciphers fracos no FTP TLS;
3. limitar tentativas de login por IP;
4. revisar permissões de diretório de contas delegadas.

Checklist de atendimento para time de suporte

Fluxo que padronizei para N1/N2:

1. confirmar protocolo usado pelo cliente (SFTP vs FTPS);
2. validar se usuário é principal ou adicional;
3. coletar log de erro do cliente;
4. testar conexão FTPS com mesma credencial;
5. registrar causa raiz no ticket para evitar recorrência.

Esse padrão elimina retrabalho e reduz chamados repetidos de “senha inválida” quando o problema é incompatibilidade de protocolo.

Conclusão

SFTP e FTPS não são substitutos no backend de autenticação. Em cPanel e DirectAdmin, contas FTP adicionais são virtuais e, por definição, não autenticam em SSH/SFTP. A rota segura e suportada para delegação é FTPS com TLS obrigatório e escopo de diretório bem definido.

Este post está licenciado sob CC BY-NC.