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, i log di sistema vengono memorizzati solo nel journal di systemd. Quindi, il comando che 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 tutte le indagini Linux. Prime Core ha 11.632 regole Sigma che operano su log di autenticazione Linux come questi, mappate su 643 tecniche MITRE ATT&CK. Tra esse: forza bruta (T1110), accessi con credenziali rubate (T1078) e movimento laterale tramite SSH (T1021.004). Di seguito è indicato come trovare i log di sshd, esportarli, sanitizzarli e indagarli gratuitamente in LogTotal.
TL;DR
| Famiglia di distribuzione | File di log | Comando del 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 | nessuno di default | journalctl -u sshd |
Prima di iniziare: puoi effettivamente leggerli?
I log di autenticazione sono bloccati per motivi di sicurezza, quindi un account regolare di solito non ottiene nulla indietro.
- /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 è accessibile a root e ai membri di systemd-journal, adm e wheel. Chiunque altro vede solo il proprio journal utente. Se esegui journalctl -u ssh come utente normale, ottieni un risultato vuoto e un suggerimento che non stai vedendo i messaggi degli altri utenti. Sono permessi, non un server tranquillo.
La soluzione semplice è sudo. Se stai configurando un account solo per la raccolta dei log, aggiungilo ad adm o systemd-journal anziché concedere root. La nostra [guida ai permessi dei log su Linux] copre i dettagli.
Un’altra cosa prima di copiare qualsiasi cosa da un server: i log di autenticazione contengono nomi utente, IP di origine e nomi host. LogTotal sanitizza gli upload, ma controlla prima le politiche di gestione dei dati.
Fase 1: File, journal o entrambi?
La tabella sopra mostra i valori predefiniti, e i valori predefiniti sono esattamente ciò che le immagini cloud e gli script di indurimento amano cambiare. Dedica dieci secondi a controllare:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Se un file appare e rsyslog è attivo, hai entrambi: rsyslog copia i messaggi dal journal in un file di testo semplice. Entrambe le fonti vanno bene, e il file è più facile da copiare.
Se non c’è nessun file, rsyslog semplicemente non è installato. È la norma ora: da Debian 12, rsyslog non fa più parte di un’installazione predefinita, quindi una nuova macchina Debian non ha auth.log. Fedora e Arch funzionano in questo modo da anni. Vai alla Fase 2b.
Mentre sei qui, controlla se il journal sopravvive a un riavvio:
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 sapere prima che qualcuno decida di “riavviarla e basta.”
Un altro punto per il lavoro sugli incidenti: se la macchina potrebbe essere compromessa, anche i suoi log locali potrebbero esserlo. Cancellare o modificare auth.log è un passo classico di pulizia. Se il server inoltra i log a un SIEM, esportali da lì e confrontali. La nostra [guida all’esportazione su Splunk] mostra come.
Fase 2a: Esportare da auth.log o secure
Il file attuale copre solo gli ultimi giorni. Le voci più vecchie si trovano nei file ruotati accanto ad esso. Su Debian e Ubuntu appaiono come 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, servono anche quelli.
Questo estrae le righe di sshd dai file attuali e ruotati, dai più vecchi ai più recenti, 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 file semplici e compressi allo stesso modo, quindi non devi decomprimere nulla. ls -tr ordina per tempo di modifica, quindi il file più vecchio va per primo e l’output rimane grosso modo cronologico. Il pattern di sshd corrisponde anche a sshd-session, il che è importante sui sistemi più recenti (vedi Fase 2b).
Perché filtrare del tutto? Oltre a ridurre il rumore, auth.log registra anche sudo, e le righe di sudo includono linee di comando complete. Ogni tanto qualcuno digita le password lì. Filtrare per sshd tiene fuori quel contenuto dal file. L’eccezione è quando stai investigando quello che un attaccante ha fatto dopo l’accesso. In quel caso vuoi anche le righe di sudo: prendi tutto il file e lascia che il passaggio di sanitizzazione di LogTotal faccia il suo lavoro.
Verifica rapida 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 syslog classico (19 Ott 10:15:01, nessun anno, nessun fuso orario) o ISO 8601 completo. Se sono classici, annota il fuso orario del server (timedatectl). Ne avrai bisogno non appena cercherai di allineare questi eventi con qualcos’altro.
Fase 2b: Esportare dal journal di systemd
Su sistemi solo journal, questo è l’intero 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 lì sono deliberate.
Entrambi i nomi delle unità. Il servizio si chiama ssh su Debian e Ubuntu e sshd quasi ovunque altrove. journalctl combina i 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. Dalla versione 9.8 di OpenSSH, il server è stato diviso in due binari, e i messaggi per connessione, inclusi gli accessi, sono taggati come sshd-session invece di sshd. Filtra per tag e perdi esattamente le righe che sei venuto a cercare. Questo ha rotto parecchie configurazioni di fail2ban e sshguard quando la versione 9.8 è arrivata nel 2024. RHEL 10 e altre versioni attuali distribuiscono OpenSSH 9.8 o versioni successive. Filtrando per unità si cattura ogni processo che appartiene al servizio, qualunque sia il suo nome.
-o short-iso. Ti dà una riga in stile syslog con un timestamp ISO 8601 completo, anno e fuso orario inclusi, quindi non devi indovinare. [PROVA: conferma che LogTotal interpreta short-iso; se no, usa il predefinito -o short]. Se preferisci mantenere ogni campo del journal (PID, ID di avvio, nome host, e così via), usa -o json, che scrive un oggetto JSON per riga. Il file diventa più grande, ma nulla viene perso.
I filtri temporali accettano anche valori relativi: –since “2 hours ago” o –since yesterday. Con un journal persistente, -b -1 limita l’output all’avvio precedente, il che aiuta se il server è stato riavviato dopo l’incidente.
Non copiare i file binari .journal da /var/log/journal e non caricarli. LogTotal legge testi e JSON, e i file journal non sono né l’uno né l’altro.
Cosa cercare una volta che hai il file
La maggior parte delle righe di sshd rientra in pochi schemi:
| La riga inizia con | Cosa significa |
|---|---|
| Password non riuscita per <utente> da <ip> | Password errata per un account che esiste |
| Utente non valido <utente> da <ip> | Il nome utente non esiste; tipico degli scanner che ciclicano tra admin, test, oracle |
| Password accettata per / Chiave pubblica accettata per | Un login riuscito; la linea chiave pubblica porta anche l’impronta digitale SHA256 della chiave |
| Scollegamento dell’utente che si sta autenticando… Troppi fallimenti di autenticazione | Il client ha raggiunto MaxAuthTries |
| Connessione chiusa da <ip>… [preauth] | Interrotto prima dell’autenticazione, di solito scanner e strumentazioni 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 Password non riuscita o Utente non valido da un IP, poi un Accettato dallo stesso IP. Questo è un attacco a forza bruta che ha funzionato. Poco dopo: un Accettato per un account servizio, da un indirizzo che nessuno riconosce, in un orario in cui nessuno lavora.
Su OpenSSH 9.8 e versioni successive potresti anche vedere messaggi sulle penalità: sshd ora rifiuta temporaneamente gli indirizzi che continuano a fallire nell’autenticazione. Trattali come un sintomo. Ti dicono che qualcuno stava martellando la porta, non che qualcuno sia entrato.
Caricare, sanitizzare e rivedere in LogTotal
Leggere qualche centinaio di righe ad occhio va bene. Leggerne 40.000 no. LogTotal è il servizio gratuito di SOC Prime per eseguire la logica di rilevamento su un file di log senza dover configurare nulla. Sanifica ciò che carichi e non mantiene i tuoi file.
- Carica. Apri logtotal.com e inserisci web-03_sshd.log. [PROVA: schermo di caricamento, limite di dimensione]
- Sanifica. [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.
- Rivedi. [PROOF: what the results screen shows and how findings map to rules and ATT&CK techniques]
Cosa sembra sui dati reali. Abbiamo generato i log di sshd su un VM di test usa e getta: [PROVA: cosa è stato simulato, es. un attacco a spruzzo di password SSH contro alcuni nomi utente comuni, terminato con un accesso riuscito]. Il file é risultato di [PROVA: N righe, X KB]. LogTotal ha segnalato [PROVA: risultati effettivi, regole corrispondenti, tecniche ATT&CK].
Vuoi provarlo prima di toccare i tuoi server? [PROVA: link al file di esempio] è lo stesso file che abbiamo usato sopra.
Quando qualcosa va storto
| Sintomo | Causa probabile | Fix |
|---|---|---|
| Nessun file o directory per auth.log | rsyslog non è installato (predefinito da Debian 12) | Usa journalctl, Fase 2b |
| Autorizzazione negata sul file log | auth.log è solo gruppo adm, secure è solo root | sudo, o aggiungi l’account ad adm |
| journalctl -u ssh non ritorna nulla, con un suggerimento sugli altri utenti | Non sei in systemd-journal, adm o wheel | sudo, o aggiungi l’account a systemd-journal |
| journalctl -u ssh non ritorna nulla come root | Nome unità errato per questa distribuzione | Usa -u ssh -u sshd |
| I logout ci sono, ma nessuna riga Accettata | 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 log vecchi sono andati; controlla il tuo SIEM o log forwarder |
| Il file copre solo pochi giorni | I file ruotati non sono stati inclusi | Usa il comando zgrep con auth.log* o secure* |
| I timestamp non coincidono con altre fonti | I timestamp syslog classici non portano fuso orario | Nota 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 cloud minimali talvolta lasciano fuori rsyslog. Se il file non c’è, usa il journal.
Come vedo solo gli accessi SSH falliti?
sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’ sui sistemi journal, o sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log* quando hai il file. Per qualsiasi cosa oltre uno sguardo rapido, carica invece l’intero log di sshd. I fallimenti significano solo qualcosa accanto ai successi.
Che dire di last e lastb?
Leggono i record di accesso binari in /var/log/wtmp e /var/log/btmp. Sono utili per un rapido sguardo a chi ha effettuato l’accesso, ma contengono molti meno dettagli rispetto al log di sshd, e sono altrettanto facili per un intruso da manomettere.
Come raccolgo i log di sshd da diversi server contemporaneamente?
Per un’occasione unica, 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 di sudo per funzionare senza un prompt della password sul lato remoto. Altrimenti, aggiungi -t a ssh e digita ogni volta. Se lo fai più di una volta a trimestre, invia i log a un SIEM invece.
È sicuro caricare i log di sshd su uno strumento online?
LogTotal sanitizza gli upload prima dell’analisi e non conserva i file; la nostra [guida alla sanitizzazione] mostra cosa viene mascherato. Le regole interne alla tua organizzazione per il trattamento dei dati hanno comunque la precedenza.
Passo successivo
Hai ottenuto il file? Caricalo su LogTotal e vedi cosa fanno quelle 11.632 regole Sigma. Se vuoi la stessa logica di rilevazione in esecuzione su tutti i tuoi server Linux, non un file alla volta.
Riferimenti
- Note di rilascio di Debian 12: cambiamenti nei log di sistema
- Note di rilascio di OpenSSH 9.8: la divisione sshd / sshd-session e i tag dei log cambiati
- journalctl(1): filtri unità, formati di output, gruppi di accesso ai journal
- journald.conf(5): archiviazione persistente vs volatili
