Seguir No Debian e Ubuntu, o sshd grava em /var/log/auth.log. No RHEL, Rocky, Alma e CentOS Stream, grava em /var/log/secure. Se nenhum dos arquivos existir, seu sistema registra apenas no journal do systemd. Então, o comando que você deseja é journalctl -u ssh em sistemas baseados no Debian, ou journalctl -u sshd na família Red Hat, Fedora e Arch.
SSH é a porta de entrada de quase todos os servidores Linux, por isso seus logs aparecem em quase todas as investigações em Linux. O Prime Core possui 11.632 regras sigma que operam em logs de autenticação Linux como estes, mapeadas para 643 técnicas MITRE ATT&CK. Entre elas: força bruta (T1110), logins com credenciais roubadas (T1078) e movimento lateral via SSH (T1021.004). Abaixo está como encontrar seus logs do sshd, exportá-los, sanitizá-los e investigá-los gratuitamente no LogTotal.
Em resumo
| Família Distro | Arquivo de log | Comando do journal |
|---|---|---|
| Debian, Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL, Rocky, Alma, CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora, Arch, instalações mínimas sem rsyslog | nenhum por padrão | journalctl -u sshd |
Antes de começar: você pode realmente lê-los?
Logs de autenticação são protegidos por uma razão, então uma conta comum geralmente não recebe nada de volta.
- /var/log/auth.log no Debian e Ubuntu é legível pelo root e pelo grupo adm.
- /var/log/secure na família Red Hat é apenas para root.
- O journal do sistema está aberto para root e para membros de systemd-journal, adm e wheel. Qualquer outro usuário vê apenas seu próprio journal. Se você executar journalctl -u ssh como um usuário normal, receberá um resultado vazio e uma dica de que você não está vendo mensagens de outros usuários. São as permissões, não um servidor silencioso.
A solução simples é sudo. Se você estiver configurando uma conta apenas para coleta de logs, adicione-a ao adm ou systemd-journal em vez de distribuir root. Nosso [guia de permissões de logs no Linux] cobre os detalhes.
Mais uma coisa antes de copiar qualquer coisa do servidor: logs de autenticação contêm nomes de usuários, IPs de origem e nomes de host. O LogTotal sanitiza uploads, mas verifique primeiro sua política de manuseio de dados.
Passo 1: Arquivo, journal, ou ambos?
A tabela acima mostra os padrões, e os padrões são exatamente o que imagens de nuvem e scripts de endurecimento gostam de alterar. Gaste dez segundos verificando:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Se um arquivo aparecer e o rsyslog estiver ativo, você tem ambos: o rsyslog copia mensagens do journal para um arquivo de texto simples. Qualquer fonte funciona, e o arquivo é mais fácil de copiar.
Se não houver arquivo, rsyslog simplesmente não está instalado. Isso é a norma agora: desde o Debian 12, rsyslog não faz mais parte de uma instalação padrão, então uma nova máquina Debian não tem auth.log. Fedora e Arch têm trabalhado assim há anos. Vá para o Passo 2b.
Enquanto você está aqui, verifique se o journal sobrevive a uma reinicialização:
ls -d /var/log/journal
Se esse diretório não existir, journald mantém os logs na memória em /run/log/journal, e uma reinicialização os apaga. Em uma máquina que você está investigando, isso é importante saber antes que alguém decida “apenas reiniciá-la”.
Mais um ponto para o trabalho de incidente: se a máquina puder estar comprometida, seus logs locais também podem estar. Limpar ou editar o auth.log é um passo de limpeza clássico. Se o servidor encaminha logs para um SIEM, exporte de lá também e compare. Nosso [guia de exportação para Splunk] mostra como.
Passo 2a: Exportar de auth.log ou secure
O arquivo atual cobre apenas os últimos dias. Entradas mais antigas estão em arquivos rotacionados ao lado dele. No Debian e Ubuntu eles se parecem com auth.log.1, auth.log.2.gz, e assim por diante. Na família Red Hat, eles carregam uma data, como secure-20261012. Se o incidente começou na semana passada, você precisará deles também.
Isso puxa linhas do sshd do arquivo atual e dos rotacionados, do mais antigo para o mais novo, em um arquivo:
# Debian / Ubuntu
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/auth.log*) > web-03_sshd.log
# RHEL / Rocky / Alma
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/secure*) > web-03_sshd.log
zgrep lê arquivos simples e comprimidos, então você não precisa descompactar nada. ls -tr ordena por tempo de modificação, então o arquivo mais antigo vem primeiro e a saída permanece aproximadamente em ordem cronológica. O padrão sshd também coincide com sshd-session, o que importa em sistemas mais novos (veja Passo 2b).
Por que filtrar? Além de reduzir o ruído, auth.log também registra sudo, e as linhas sudo incluem linhas de comando completas. Às vezes, pessoas digitam senhas nelas. Filtrar para sshd mantém isso fora do arquivo. A exceção é quando você está investigando o que um atacante fez depois de fazer login. Então você quer também as linhas sudo: pegue o arquivo completo e deixe o passo de sanitização do LogTotal fazer seu trabalho.
Verificação rápida antes de fazer upload:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
Olhe para os carimbos de data/hora. Dependendo da configuração do rsyslog, eles são ou syslog clássico (19 de Out 10:15:01, sem ano, sem fuso horário) ou ISO 8601 completo. Se forem clássicos, anote o fuso horário do servidor (timedatectl). Você precisará dele assim que tentar alinhar esses eventos com qualquer outra coisa.
Passo 2b: Exportar do journal do systemd
Em sistemas apenas com journal, este é o trabalho completo:
sudo journalctl -u ssh -u sshd
–since “2026-10-19 00:00” –until “2026-10-20 00:00”
–no-pager -o short-iso > web-03_sshd.log
Algumas escolhas aí são deliberadas.
Ambos os nomes de unidade. O serviço é chamado ssh no Debian e Ubuntu e sshd quase em qualquer outro lugar. o journalctl combina flags repetidas -u com OR, então o mesmo comando funciona em ambas as famílias.
Filtrar por unidade, não por tag. Muitos guias antigos usam journalctl -t sshd. Desde o OpenSSH 9.8, o servidor é dividido em dois binários, e mensagens por conexão, incluindo logins, são marcadas como sshd-session em vez de sshd. Filtrar por tag, e você perde exatamente as linhas pelas quais veio. Isso quebrou muitas configurações de fail2ban e sshguard quando o 9.8 foi lançado em 2024. O RHEL 10 e outras versões atuais lançam o OpenSSH 9.8 ou mais recente. Filtrar por unidade captura cada processo que pertence ao serviço, qualquer que seja o nome.
-o short-iso. Fornece uma linha ao estilo syslog com um carimbo de data/hora ISO 8601 completo, incluindo ano e fuso horário, então você não precisa adivinhar. Se preferir manter cada campo do journal (PID, ID de inicialização, nome do host etc.), use -o json, que escreve um objeto JSON por linha. O arquivo fica maior, mas nada é perdido.
Os filtros de tempo também aceitam valores relativos: –since “2 hours ago” ou –since yesterday. Com um journal persistente, -b -1 limita a saída à inicialização anterior, o que ajuda se o servidor foi reiniciado após o incidente.
Não copie os arquivos .journal binários de /var/log/journal e faça o upload deles. O LogTotal lê texto e JSON, e os arquivos de journal não são nem um nem outro.
O que procurar uma vez que você tenha o arquivo
A maioria das linhas sshd cai em alguns poucos padrões:
| Linha começa com | O que significa |
|---|---|
| Senha incorreta para <usuário> de <ip> | Senha errada para uma conta que existe |
| Usuário inválido <usuário> de <ip> | O nome de usuário não existe; típico de scanners passando por admin, test, oracle |
| Senha aceita para / Chave pública aceita para | Um login bem-sucedido; a linha publickey também carrega a impressão digital SHA256 da chave |
| Desconectando usuário autenticante … Muitas falhas de autenticação | O cliente atingiu MaxAuthTries |
| Conexão fechada por <ip> … [preauth] | Desconectado antes da autenticação, geralmente scanners e capturadores de banners |
| pam_unix(sshd:session): sessão aberta para usuário | A sessão realmente começou |
A sequência que vale a pena parar: uma série de linhas de senha incorreta ou usuário inválido de um IP, seguida por uma senha aceita do mesmo IP. Isso é uma força bruta que funcionou. Logo atrás: uma senha aceita para uma conta de serviço, de um endereço que ninguém reconhece, em uma hora que ninguém está trabalhando.
No OpenSSH 9.8 e posteriores você também pode ver mensagens sobre penalidades: o sshd agora recusa temporariamente endereços que continuam falhando na autenticação. Trate-as como sintoma. Elas indicam que alguém estava martelando na porta, não que alguém entrou.
Faça upload, sanitize e reveja no LogTotal
Ler algumas centenas de linhas a olho é viável. Ler 40.000 não é. O LogTotal é o serviço gratuito da SOC Prime para executar lógica de detecção contra um arquivo de log sem precisar configurar nada. Ele sanitiça o que você faz upload e não mantém seus arquivos.
- Fazer upload. Acesse logtotal.com e solte o arquivo web-03_sshd.log.
- Sanitize. Revise o resultado antes de prosseguir. Você sabe quais desses nomes são sensíveis em seu ambiente.
- Rever.
Quando algo dá errado
| Sintoma | Causa provável | Fix |
|---|---|---|
| Arquivo ou diretório não encontrado para auth.log | rsyslog não está instalado (padrão desde o Debian 12) | Use journalctl, Passo 2b |
| Permissão negada no arquivo de log | auth.log é só para adm, secure é apenas para root | sudo, ou adicione a conta a adm |
| journalctl -u ssh não retorna nada, com uma dica sobre outros usuários | Você não está em systemd-journal, adm ou wheel | sudo, ou adicione a conta a systemd-journal |
| journalctl -u ssh não retorna nada como root | Nome de unidade errado para esta distro | Use -u ssh -u sshd |
| Logouts estão lá, mas sem linhas de aceitação | Filtrando por tag (-t sshd) no OpenSSH 9.8+ | Filtre por unidade |
| Nada mais antigo que a última reinicialização | Journal volátil; sem /var/log/journal | Os logs antigos se foram; verifique seu SIEM ou encaminhador de logs |
| O arquivo cobre apenas alguns dias | Arquivos rotacionados não foram incluídos | Use o comando zgrep com auth.log* ou secure* |
| Carimbos de data/hora não se alinham com outras fontes | Carimbos de data/hora do syslog clássico não carregam fuso horário | Observe o fuso horário do servidor, ou exporte com -o short-iso |
FAQ
Onde estão os logs do SSH no Ubuntu?
Em uma instalação padrão no Ubuntu, em /var/log/auth.log, além do journal (journalctl -u ssh). Imagens de nuvem mínimas às vezes deixam de fora o rsyslog. Se o arquivo não estiver lá, use o journal.
Como vejo apenas logins SSH falhos?
sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’ em sistemas com journal, ou sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log* quando você tiver o arquivo. Para algo além de uma rápida inspeção, faça o upload do log completo do sshd. As falhas só significam algo ao lado dos sucessos.
E quanto ao last e lastb?
Eles leem os registros binários de login em /var/log/wtmp e /var/log/btmp. São úteis para uma rápida visualização de quem fez login, mas carregam bem menos detalhes do que o próprio log do sshd, e são igualmente fáceis para um intruso adulterar.
Como coleto logs do sshd de vários servidores ao mesmo tempo?
Para uma única vez, um loop faz isso: for h in web-01 web-02 web-03; do ssh “$h” “sudo journalctl -u ssh -u sshd –since yesterday -o short-iso –no-pager” > “${h}_sshd.log” done Isso precisa de sudo para funcionar sem um prompt de senha no lado remoto. Caso contrário, adicione -t ao ssh e digite cada vez. Se você estiver fazendo isso mais de uma vez por trimestre, envie os logs para um SIEM.
É seguro fazer upload de logs do sshd para uma ferramenta online?
O LogTotal sanitiza uploads antes da análise e não retém arquivos; nosso [guia de sanitização] mostra o que é mascarado. As regras de manuseio de dados da sua organização ainda são prioritárias.
Próximo passo
Tem o arquivo? Faça o upload para o LogTotal e veja o que essas 11.632 regras sigma fazem com ele. Se você quiser a mesma lógica de detecção rodando em todos os seus servidores Linux, e não um arquivo por vez.
Referências
- Notas de lançamento do Debian 12: alterações no registro de sistema
- Notas de lançamento do OpenSSH 9.8: a divisão sshd / sshd-session e mudança nas tags de log
- journalctl(1): filtros de unidade, formatos de saída, grupos de acesso ao journal
- journald.conf(5): armazenamento persistente vs volátil
