Segui Su Debian e Ubuntu, sshd scrive su /var/log/auth.log. Su RHEL, Rocky, Alma e CentOS Stream, scrive su /var/log/secure. Se nessuno dei due file esiste, il tuo sistema registra solo nel journal di systemd. Quindi il comando che ti serve è journalctl -u ssh sui sistemi basati su Debian, o journalctl -u sshd sulla famiglia Red Hat, Fedora e Arch.
SSH è la porta principale di quasi ogni server Linux, motivo per cui i suoi log appaiono in quasi ogni indagine su Linux. Prime Core ha 11.632 regole sigma che girano sui log di autenticazione Linux come questi, mappati a 643 tecniche MITRE ATT&CK. Tra queste: forza bruta (T1110), accessi con credenziali rubate (T1078) e movimento laterale tramite SSH (T1021.004). Di seguito è riportato come trovare i tuoi log sshd, esportarli, sanificarli e indagarli gratuitamente in LogTotal.
TL;DR
| Famiglia di distribuzione | File di log | Comando Journal |
|---|---|---|
| Debian, Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL, Rocky, Alma, CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora, Arch, installazioni minimali senza rsyslog | niente di default | journalctl -u sshd |
Prima di iniziare: riesci effettivamente a leggerli?
I log di autenticazione sono chiusi intenzionalmente, quindi un account normale di solito non riceve nulla.
- /var/log/auth.log su Debian e Ubuntu è leggibile da root e dal gruppo adm.
- /var/log/secure sulla famiglia Red Hat è solo per root.
- Il journal di sistema è aperto a root e ai membri di systemd-journal, adm e wheel. Gli altri vedono solo il proprio user journal. Se esegui journalctl -u ssh come utente normale, ottieni un risultato vuoto e un suggerimento che non stai vedendo messaggi da altri utenti. Sono permessi, non un server silenzioso.
La soluzione semplice è sudo. Se stai configurando un account solo per la raccolta dei log, aggiungilo ad adm o systemd-journal invece di distribuire root. La nostra guida ai permessi dei log su Linux copre i dettagli.
Prima di copiare qualcosa da un server: i log di autenticazione contengono nomi utente, IP di origine e nomi host. LogTotal sanitizza gli upload, ma controlla prima la tua politica di gestione dei dati.
Passo 1: File, journal, o entrambi?
La tabella sopra mostra i default, e i default sono esattamente ciò che le immagini in cloud e gli script di hardening amano cambiare. Impiega dieci secondi per controllare:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Se appare un file e rsyslog è attivo, li hai entrambi: rsyslog copia i messaggi fuori dal journal in un file di testo. Entrambe le fonti funzionano, e il file è più facile da copiare.
Se non c’è file, rsyslog semplicemente non è installato. È la norma ora: da Debian 12, rsyslog non fa più parte di un’installazione predefinita, quindi un nuovo box Debian non ha auth.log. Fedora e Arch funzionano in questo modo da anni. Vai al Passo 2b.
Mentre sei qui, controlla se il journal sopravvive a un reboot:
ls -d /var/log/journal
Se quella directory non esiste, journald tiene i log in memoria sotto /run/log/journal, e un riavvio li cancella. Su una macchina che stai indagando, vale la pena saperlo prima che qualcuno decida di “riavviarla”.
Un altro punto per il lavoro sugli incidenti: se il box potrebbe essere compromesso, anche i log locali potrebbero esserlo. Cancellare o modificare auth.log è una classica fase di pulizia. Se il server inoltra i log a un SIEM, esporta anche da lì e confronta. La nostra guida all’export da Splunk mostra come fare.
Passo 2a: Esporta da auth.log o secure
Il file corrente copre solo gli ultimi giorni. Le voci più vecchie si trovano nei file ruotati accanto ad esso. Su Debian e Ubuntu sembrano auth.log.1, auth.log.2.gz e così via. Sulla famiglia Red Hat portano una data, come secure-20261012. Se l’incidente è iniziato la settimana scorsa, hai bisogno anche di quelli.
Questo estrae le righe di sshd dai file attuali e ruotati, dal più vecchio al più recente, in un unico file:
# 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 legge sia file normali che compressi, quindi non devi decomprimere nulla. ls -tr ordina per data di modifica, quindi il file più vecchio viene prima e l’output resta approssimativamente cronologico. Il pattern sshd corrisponde anche a sshd-session, che è importante sui sistemi più recenti (vedi Step 2b).
Perché filtrare? Oltre a ridurre il rumore, auth.log registra anche sudo, e le righe sudo includono le linee di comando complete. A volte le persone digitano password in queste. Filtrare a sshd mantiene fuori questo dal file. L’eccezione è quando stai investigando su cosa ha fatto un attaccante dopo l’accesso. Allora vuoi anche le righe sudo: prendi l’intero file e lascia che il passo di sanificazione di LogTotal faccia il suo lavoro.
Controllo rapido prima di caricare:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
Guarda i timestamp. A seconda della configurazione di rsyslog, sono o classici syslog (19 Ott 10:15:01, senza anno e fuso orario) o completi ISO 8601. Se sono classici, annota il fuso orario del server (timedatectl). Ne avrai bisogno quando cerchi di allineare questi eventi con qualsiasi altra cosa.
Passo 2b: Esporta dal journal di systemd
Su sistemi solo journal, questo è tutto il lavoro:
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
Alcune scelte tra cui scegliere.
Entrambi i nomi delle unità. Il servizio si chiama ssh su Debian e Ubuntu e sshd quasi ovunque altrove. journalctl combina flag -u ripetuti con OR, quindi lo stesso comando funziona su entrambe le famiglie.
Filtra per unità, non per tag. Molte guide più vecchie usano journalctl -t sshd. Da OpenSSH 9.8, il server è diviso in due binari e i messaggi per connessione, incluso l’accesso, sono etichettati come sshd-session invece di sshd. Filtra per tag e perdi proprio le righe che cercavi. Questo ha rotto molti setup di fail2ban e sshguard quando 9.8 è arrivata nel 2024. RHEL 10 e altre versioni attuali spediscono OpenSSH 9.8 o più recenti. Filtrare per unità cattura ogni processo che appartiene al servizio, qualunque sia il suo nome.
-o short-iso. Ti dà una linea in stile syslog con un timestamp completo ISO 8601, anno e fuso orario inclusi, così non devi indovinare. Se preferisci mantenere ogni campo del journal (PID, boot ID, hostname, e così via), usa -o json, che scrive un oggetto JSON per linea. Il file si ingrandisce, ma nulla va perso.
I filtri temporali prendono anche valori relativi: –since “2 hours ago” o –since yesterday. Con un journal persistente, -b -1 limita l’output al boot precedente, utile se il server è stato riavviato dopo l’incidente.
Non copiare i file binari .journal da /var/log/journal e caricarli. LogTotal legge testo e JSON, e i file di journal non sono né l’uno né l’altro.
Cosa cercare una volta che hai il file
La maggior parte delle righe sshd rientra in alcuni modelli:
| La riga inizia con | Cosa significa |
|---|---|
| Password errata per <utente> da <ip> | Password sbagliata per un account esistente |
| Utente invalido <utente> da <ip> | Il nome utente non esiste; tipico degli scanner che ciclicano attraverso admin, test, oracle |
| Password accettata per / Chiave pubblica accettata per | Un accesso riuscito; la linea chiave pubblica porta anche l’impronta SHA256 della chiave |
| Scollegamento utente autenticato … Troppi tentativi di autenticazione | Il client ha raggiunto MaxAuthTries |
| Connessione chiusa da <ip> … [preauth] | Interrotta prima dell’autenticazione, di solito scanner e grabber di banner |
| pam_unix(sshd:session): sessione aperta per l’utente | La sessione è effettivamente iniziata |
La sequenza che vale la pena fermare: una serie di righe Failed o Invalid user dallo stesso IP, poi un Accepted dallo stesso IP. Questo è un attacco brute force che è riuscito. Subito dopo: un Accepted per un account di servizio, da un indirizzo che nessuno riconosce, ad un’ora in cui nessuno lavora.
Su OpenSSH 9.8 e successive puoi anche vedere messaggi sulle sanzioni: sshd ora rifiuta temporaneamente indirizzi che continuano a fallire l’autenticazione. Considerale un sintomo. Ti dicono che qualcuno stava martellando la porta, non che qualcuno sia effettivamente entrato.
Carica, sanifica e rivedi in LogTotal
Leggere qualche centinaio di righe a occhio è fattibile. Leggerne 40.000 no. LogTotal è il servizio gratuito di SOC Prime per eseguire logiche di rilevamento contro un file di log senza impostare nulla. Sanifica ciò che carichi e non conserva i tuoi file.
- Caricare. Aprire logtotal.com e caricare web-03_sshd.log.
- Sanificare. Esamina il risultato prima di procedere. Sai quali di quei nomi sono sensibili nel tuo ambiente.
- Revisione.
Quando qualcosa va storto
| Sintomo | Causa probabile | Fix |
|---|---|---|
| Nessun file o directory per auth.log | rsyslog non è installato (default da Debian 12) | Usa journalctl, Step 2b |
| Permesso negato sul file di log | auth.log è solo per adm, secure è solo per root | sudo, o aggiungi l’account a adm |
| journalctl -u ssh non restituisce nulla, con un suggerimento riguardante altri utenti | Non sei in systemd-journal, adm o wheel | sudo, o aggiungi l’account a systemd-journal |
| journalctl -u ssh non restituisce nulla come root | Nome di unità sbagliato per questa distribuzione | Usa -u ssh -u sshd |
| I logout ci sono, ma nessuna riga Accepted | Filtraggio per tag (-t sshd) su OpenSSH 9.8+ | Filtra per unità invece |
| Niente di più vecchio dell’ultimo riavvio | Journal volatile; nessun /var/log/journal | I vecchi log sono andati; controlla il tuo SIEM o il forwarder di log |
| Il file copre solo pochi giorni | File rotati non sono stati inclusi | Usa il comando zgrep con auth.log* o secure* |
| I timestamp non si allineano con altre fonti | I timestamp syslog classici non hanno fuso orario | Annota il fuso orario del server, o esporta con -o short-iso |
FAQ
Dove sono i log SSH su Ubuntu?
Su un’installazione standard di Ubuntu, in /var/log/auth.log, più il journal (journalctl -u ssh). Le immagini minimali in cloud a volte omettono rsyslog. Se il file non è presente, usa il journal.
Come posso vedere solo gli accessi SSH falliti?
sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’ su sistemi journal, o sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log* quando hai il file. Per qualsiasi cosa oltre a un rapido sguardo, carica invece l’intero log sshd. I fallimenti significano qualcosa solo accanto ai successi.
Che dire di last e lastb?
Leggono i record di login binari in /var/log/wtmp e /var/log/btmp. Sono utili per un rapido sguardo a chi ha effettuato login, ma portano molti meno dettagli rispetto al log di sshd stesso, e sono altrettanto facili da manomettere per un intruso.
Come posso raccogliere i log sshd da più server in una volta?
Per una volta sola, un ciclo lo fa: 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 Questo necessita che sudo lavori senza richiesta di password sul lato remoto. Altrimenti, aggiungi -t a ssh e digitale ogni volta. Se lo fai più di una volta al trimestre, invia i log a un SIEM invece.
È sicuro caricare i log sshd su uno strumento online?
LogTotal sanifica gli upload prima dell’analisi e non conserva i file; la nostra guida alla sanificazione mostra cosa viene mascherato. Le regole di gestione dei dati della tua organizzazione vengono comunque prima.
Passo successivo
Hai il file? Caricalo su LogTotal e guarda cosa ne fanno di quelle 11.632 regole sigma. Se vuoi la stessa logica di rilevamento in esecuzione su tutti i tuoi server Linux, non uno alla volta.
Riferimenti
- Note di rilascio di Debian 12: cambiamenti alla registrazione del sistema
- Note di rilascio OpenSSH 9.8: la divisione sshd / sshd-session e cambiati i tag di log
- journalctl(1): filtri per unità, formati di output, gruppi di accesso al journal
- journald.conf(5): storage persistente vs volatile
