Seguir No Debian e Ubuntu, o sshd grava em /var/log/auth.log. No RHEL, Rocky, Alma e CentOS Stream, ele grava em /var/log/secure. Se nenhum dos arquivos existir, seu sistema registra logs apenas no journal do systemd. Então, o comando que você quer é journalctl -u ssh em sistemas baseados em Debian, ou journalctl -u sshd na família Red Hat, Fedora e Arch.
SSH é a porta de entrada de quase todos os servidores Linux, e é por isso que seus logs aparecem em quase todas as investigações de Linux. Prime Core possui 11.632 regras sigma que operam em logs de autenticação Linux como este, mapeadas para 643 técnicas MITRE ATT&CK. Entre elas: força bruta (T1110), logins com credenciais roubadas (T1078) e movimento lateral através de SSH (T1021.004). Abaixo está como encontrar seus logs sshd, exportá-los, sanitizá-los e investigá-los gratuitamente no LogTotal.
Experimente o LogTotal, grátis
Resumidamente
| 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ê consegue realmente lê-los?
Logs de autenticação são protegidos intencionalmente, portanto, uma conta regular geralmente não recebe nenhum retorno.
- /var/log/auth.log no Debian e Ubuntu é legível pelo root e pelo grupo adm.
- /var/log/secure na família Red Hat é somente para root.
- O journal do sistema está aberto para root e para membros de systemd-journal, adm e wheel. Qualquer outra pessoa vê apenas o journal de seu próprio usuário. Se você executar journalctl -u ssh como um usuário normal, obterá um resultado vazio e uma dica de que você não está vendo mensagens de outros usuários. Isso é permissão, não um servidor silencioso.
A correção simples é sudo. Se estiver configurando uma conta apenas para a coleta de logs, adicione-a a adm ou systemd-journal em vez de distribuir root. Nosso [guia de permissões de logs do Linux] cobre os detalhes.
Uma coisa a mais antes de copiar qualquer coisa de um servidor: logs de autenticação contêm nomes de usuário, IPs de origem e nomes de host. O LogTotal sanitiza carregamentos, mas verifique primeiro sua política de manuseio de dados.
Passo 1: Arquivo, journal, ou ambos?
A tabela acima mostra os padrões, e padrões são exatamente o que imagens de nuvem e scripts de endurecimento gostam de mudar. 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 rsyslog estiver ativo, você tem ambos: 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 um arquivo, rsyslog simplesmente não está instalado. Isso é o normal agora: desde o Debian 12, rsyslog não faz mais parte de uma instalação padrão, então uma nova caixa Debian não tem auth.log algum. Fedora e Arch funcionam 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 logs na memória em /run/log/journal, e uma reinicialização os apaga. Em uma máquina que você está investigando, isso é bom saber antes que alguém decida “apenas reiniciá-la”.
Outro ponto para o trabalho de incidente: se o sistema pode estar comprometido, seus logs locais também podem estar. Limpar ou editar auth.log é um passo clássico de limpeza. Se o servidor encaminhar logs para um SIEM, exporte de lá também e compare. Nosso [guia de exportação do Splunk] mostra como.
Passo 2a: Exportar de auth.log ou secure
O arquivo atual cobre apenas os últimos dias. Entradas mais antigas ficam em arquivos rotacionados ao lado dele. No Debian e Ubuntu, eles parecem auth.log.1, auth.log.2.gz, e assim por diante. Na família Red Hat, eles têm uma data, como secure-20261012. Se o incidente começou na semana passada, você precisará deles também.
Isso puxa linhas sshd dos arquivos atuais e rotacionados, do mais antigo para o mais recente, 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 normais e compactados da mesma forma, então você não precisa descompactar nada. ls -tr classifica por tempo de modificação, então o arquivo mais antigo vai primeiro e a saída permanece aproximadamente cronológica. O padrão sshd também corresponde a sshd-session, o que importa em sistemas mais recentes (veja o Passo 2b).
Por que filtrar? Além de cortar ruído, o auth.log também grava sudo, e linhas sudo incluem linhas de comando completas. Pessoas ocasionalmente digitam senhas nelas. Filtrar para sshd mantém isso fora do arquivo. A exceção é quando você está investigando o que um atacante fez após o login. Então você também quer as linhas sudo: pegue o arquivo inteiro e deixe a etapa de sanificação do LogTotal fazer o seu trabalho.
Verificação rápida antes de carregar:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
Olhe para os timestamps. Dependendo da configuração do rsyslog, eles são ou no formato clássico syslog (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á disso no momento em que tentar alinhar esses eventos com qualquer outra coisa.
Passo 2b: Exportar do journal do systemd
Em sistemas apenas de journal, este é todo o trabalho:
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 aqui são deliberadas.
Ambos os nomes das unidades. O serviço é chamado ssh no Debian e Ubuntu, e sshd quase em todo lugar mais. journalctl combina flags -u repetidos com OR, então o mesmo comando funciona em ambas as famílias.
Filtrar por unidade, não por tag. Muitos guias mais 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 faz você perder exatamente as linhas que você veio procurar. Isso quebrou muitos setups de fail2ban e sshguard quando o 9.8 foi lançado em 2024. RHEL 10 e outros lançamentos atuais despacham OpenSSH 9.8 ou mais recente. Filtragem por unidade captura cada processo que pertence ao serviço, seja qual for o nome.
-o short-iso. Isso oferece uma linha no estilo syslog com timestamp ISO 8601 completo, ano e fuso horário incluído, então você não precisa adivinhar. [PROVA: confirmar que o LogTotal analisa short-iso; se não, use o padrão -o short]. Se preferir manter cada campo do journal (PID, ID do boot, nome do host, e assim por diante), use -o json, que grava um objeto JSON por linha. O arquivo fica maior, mas nada é perdido.
Os filtros de tempo também aceitam valores relativos: –since “2 horas atrás” ou –since ontem. Com um journal persistente, -b -1 limita a saída ao boot anterior, o que ajuda se o servidor foi reiniciado após o incidente.
Não copie os arquivos binários .journal de /var/log/journal e os carregue. O LogTotal lê texto e JSON, e 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 se encaixa em alguns padrões:
| A linha começa com | O que isso significa |
|---|---|
| Failed password for <user> from <ip> | Senha errada para uma conta que existe |
| Invalid user <user> from <ip> | O nome de usuário não existe; típico de scanners passando por admin, test, oracle |
| Accepted password for / Accepted publickey for | Um login bem-sucedido; a linha publickey também carrega a impressão digital SHA256 da chave |
| Disconnecting authenticating user … Too many authentication failures | O cliente atingiu o MaxAuthTries |
| Connection closed by <ip> … [preauth] | Desconectado antes da autenticação, geralmente scanners e capturadores de banners |
| pam_unix(sshd:session): session opened for user | A sessão realmente começou |
A sequência que vale a pena parar: uma corrida de linhas Failed ou Invalid user de um IP, então um Accepted do mesmo IP. Isso é uma força bruta que funcionou. Logo atrás: um Accepted para uma conta de serviço, de um endereço que ninguém reconhece, em uma hora que ninguém trabalha.
No OpenSSH 9.8 e posterior, você também pode ver mensagens sobre penalidades: o sshd agora recusa temporariamente endereços que continuam falhando na autenticação. Trate-os como um sintoma. Eles dizem que alguém estava martelando a porta, não que alguém conseguiu entrar.
Carregue, sanitize e revise no LogTotal
Ler algumas centenas de linhas com os olhos é bem. 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 configurar nada. Ele sanitiza o que você carrega e não mantém seus arquivos.
- Carregue. Abra logtotal.com e insira web-03_sshd.log. [PROVA: tela de upload, limite de tamanho]
- Sanitize. [PROOF: what gets masked in an sshd log: usernames, source IPs, hostnames]. Look over the result before you go on. You know which of those names are sensitive in your environment.
- Revise. [PROOF: what the results screen shows and how findings map to rules and ATT&CK techniques]
Como isso parece em dados reais. Geramos logs sshd em uma VM de teste descartável: [PROVA: o que foi simulado, por exemplo, uma execução de pulverização de senha SSH contra alguns nomes de usuário comuns, terminando em um login bem-sucedido]. O arquivo resultou em [PROVA: N linhas, X KB]. LogTotal sinalizou [PROVA: achados reais, regras correspondentes, técnicas ATT&CK].
Quer tentar antes de tocar seus próprios servidores? [PROVA: link para o arquivo de amostra] é o mesmo arquivo que usamos acima.
Quando dá errado
| Sintoma | Causa provável | Fix |
|---|---|---|
| Nenhum arquivo ou diretório 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 é apenas para adm, secure é apenas para root | sudo, ou adicione a conta ao 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 ao 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 presentes, mas não há linhas Accepted | Filtragem por tag (-t sshd) no OpenSSH 9.8+ | Filtre por unidade em vez disso |
| Nada mais antigo que a última reinicialização | Journal volátil; sem /var/log/journal | Os logs antigos 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* |
| Timestamps não se alinham com outras fontes | Timestamps clássicos do syslog não possuem fuso horário | Anote o fuso horário do servidor, ou exporte com -o short-iso |
FAQ
Onde estão os logs SSH no Ubuntu?
Em uma instalação padrão do Ubuntu, em /var/log/auth.log, além do journal (journalctl -u ssh). Imagens de nuvem mínimas às vezes deixam de fora rsyslog. Se o arquivo não estiver lá, use o journal.
Como vejo apenas logins SSH falhados?
sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’ em sistemas de journal, ou sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log* quando você tem o arquivo. Para qualquer coisa além de uma rápida olhada, carregue o log completo do sshd. Os fracassos só significam algo ao lado dos sucessos.
E sobre last e lastb?
Eles leem os registros de login binários em /var/log/wtmp e /var/log/btmp. Eles são úteis para uma rápida olhada em quem fez login, mas trazem muito menos detalhes do que o próprio log do sshd, e são tão fáceis de um invasor manipular.
Como coleto logs sshd de vários servidores de uma só vez?
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 que sudo funcione sem uma solicitação de senha no lado remoto. Caso contrário, adicione -t ao ssh e digite-a a cada vez. Se você estiver fazendo isso mais de uma vez por trimestre, envie os logs para um SIEM em vez disso.
É seguro carregar logs do sshd para uma ferramenta online?
O LogTotal sanitiza os 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 vêm em primeiro lugar.
Próximo passo
Conseguiu o arquivo? Carregue-o no 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, não um arquivo de cada vez.
Referências
- Notas de lançamento do Debian 12: alterações no registro do 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
