Dove sono i log
| Sistema | Leggi i log con |
|---|---|
| Debian o Ubuntu, con systemd | sudo journalctl -u ssh |
| Red Hat o Fedora, con systemd | sudo journalctl -u sshd |
| Debian o Ubuntu con rsyslog | /var/log/auth.log |
| Famiglia Red Hat con rsyslog | /var/log/secure |
Un file può mancare, ed è normale: Debian non installa rsyslog per impostazione predefinita dalla versione 12, quindi un sistema Debian nuovo ha spesso solo il journal.
Con journalctl
sudo journalctl -u ssh --since today
sudo journalctl -u ssh --since "2 hours ago" --grep 'Accepted|Failed|Invalid'
sudo journalctl -u ssh -f-f segue le nuove righe man mano che arrivano, utile quando stai provando un login.
Con i file di testo
sudo grep Accepted /var/log/auth.log
sudo grep -E 'Failed password|Invalid user' /var/log/auth.logLe righe più vecchie possono stare in /var/log/auth.log.1 e nei file compressi accanto. Da OpenSSH 9.8 queste righe portano il nome sshd-session invece di sshd, quindi un filtro o uno script che cerca sshd[ su un sistema attuale non trova nulla.
Cosa significano le righe
Sono tutte righe reali di un server di prova, con l'indirizzo cambiato.
sshd-session[1329]: Accepted publickey for user from 203.0.113.10 port 43594 ssh2: ED25519 SHA256:NxFS05Q+k1zf...
sshd-session[1339]: Accepted password for user from 203.0.113.10 port 43598 ssh2Qualcuno ha fatto login. Sono le righe da leggere per prime. La prima mostra quale chiave è stata usata. Vedi come revocare una chiave se ne trovi una che non vuoi.
sshd-session[1311]: Failed password for user from 203.0.113.10 port 33598 ssh2Una password sbagliata per un account che esiste.
sshd-session[1317]: Invalid user admin from 203.0.113.10 port 50898
sshd-session[1317]: Failed password for invalid user admin from 203.0.113.10 port 50898 ssh2Un tentativo su un account che non esiste su questo sistema. Così appare la maggior parte dei tentativi automatici.
sshd-session[1326]: Connection closed by authenticating user user 203.0.113.10 port 43590 [preauth]Il client ha rinunciato durante il login. Con i login a chiave, di solito significa che una chiave è stata offerta e non accettata. Per impostazione predefinita il log non dice quale.
sshd-session[1317]: error: maximum authentication attempts exceeded for invalid user admin from 203.0.113.10 port 50898 ssh2 [preauth]Il client ha superato MaxAuthTries ed è stato scollegato.
Contare i tentativi per indirizzo e utente
# Which addresses
sudo grep -E 'Failed password|Invalid user' /var/log/auth.log \
| grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20
# Which user names they try
sudo grep -oE 'Invalid user [^ ]+' /var/log/auth.log \
| awk '{print $3}' | sort | uniq -c | sort -rn | head -20Un singolo tentativo di solito produce sia una riga Failed sia una Invalid user, quindi considera i numeri come indicativi. Con il journal, inizia così la prima pipeline:
sudo journalctl -u ssh --since today --no-pager | grep -E 'Failed password|Invalid user' \
| grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20Vedere chi è connesso ora
who
wEntrambi elencano le sessioni con un terminale. Un comando eseguito come ssh server somecommand, un trasferimento di file o un tunnel non compaiono. Per vedere tutte le connessioni, anche quelle:
sudo ss -tnp state established '( sport = :22 )'Cambia 22 se il tuo server usa un'altra porta. Abbiamo visto la connessione in questo elenco quando who non mostrava nulla.
Sessioni passate: last e lastb
last -a -n 20
sudo lastb -a -n 20last legge i login passati e lastb quelli falliti. -a mette l'indirizzo nell'ultima colonna. Nelle nostre prove sono emersi due limiti:
lastmostrava solo le sessioni con un terminale. Un login che ha solo eseguito un comando non lasciava nulla, quindi i file di log sono la registrazione più completa.- Su Debian 13 questi comandi non ci sono più. Il pacchetto
util-linuxnon include piùlastnélastb. Installawtmpdbelibpam-wtmpdbper riaverelast, cosa che nella nostra prova ha funzionato, per le sessioni successive all'installazione. Per i fallimenti non c'è un sostituto che legga il vecchio file. Le note di rilascio suggerisconolslogins --failed, ma nella nostra prova non mostrava nulla, quindi usa i log.
Vedere quale chiave è stata rifiutata
Per registrare anche l'impronta delle chiavi che falliscono, imposta questo in un file in /etc/ssh/sshd_config.d/ e ricarica:
LogLevel VERBOSEsshd-session[1376]: Failed publickey for user from 203.0.113.10 port 43612 ssh2: RSA SHA256:R3PypHnQ7AMz...Cosa fare con ciò che trovi
- Molti fallimenti da molti indirizzi: è comune su qualsiasi server aperto a internet. Se il server accetta solo chiavi, i tentativi di indovinare la password non possono riuscire. Vedi come disattivare il login con password e, per ridurre il rumore, fail2ban.
- Una riga
Acceptedche non sai spiegare: prendila sul serio. Annota ora, indirizzo e chiave. Rimuovi quell'accesso, guarda cosa ha fatto l'account e, se non sei sicuro di cosa sia successo, ricostruisci il server da uno stato pulito.
Chi ha root può modificare i log locali, quindi per i server importanti inviali anche a un'altra macchina.
Per rendere inutili i tentativi sulle password, genera una chiave SSH Ed25519 e accetta solo chiavi.
Domande
Come vedo i tentativi di accesso SSH falliti?
Sui sistemi con systemd esegui sudo journalctl -u ssh --grep 'Failed|Invalid' (sshd su Red Hat). Con i log di testo, cerca 'Failed password' in /var/log/auth.log o /var/log/secure con grep. sudo lastb elenca i fallimenti dove è installato.
Dov'è il log di SSH su Ubuntu?
Nel journal, da leggere con sudo journalctl -u ssh, e in /var/log/auth.log quando c'è rsyslog, che su Ubuntu è installato di base.
Molti accessi SSH falliti sono un problema?
Su un server pubblico sono il normale rumore di fondo dei bot, e non possono riuscire se il server accetta solo chiavi. La riga da prendere sul serio è un Accepted che non sai spiegare.
Fonti
- journalctl(1), systemd
- Note di rilascio di Debian 13, problemi di cui essere a conoscenza
- Note di rilascio di Debian 12, modifiche al logging di sistema
- sshd_config(5), LogLevel