Chi è collegato al tuo server Linux e chi lo è stato

La risposta breve

Per sapere chi è collegato al tuo server Linux in questo momento usa w, who e loginctl list-sessions. Per sapere chi si è collegato prima usa last e le righe di sshd nel journal, con journalctl -u ssh.service. In entrambi i casi guarda prima due cose: l'indirizzo IP di provenienza e l'ora.

Su Ubuntu 26.04 alcuni di questi comandi possono non rispondere, o non esistere. who può restare vuoto su un'immagine non aggiornata. lastb e il vecchio lastlog non ci sono più, e last arriva da un pacchetto nuovo. Questa guida spiega il motivo, così sai quale fonte è affidabile sul tuo sistema. Lancia ogni comando sul tuo server e confronta l'output con quello che descrivo.

Chi è collegato adesso: w, who, users e loginctl

Apri una sessione SSH e lancia questi comandi uno dopo l'altro.

w
who -a -H
users
loginctl list-sessions
loginctl list-users

w viene dal pacchetto procps. Per ogni utente mostra il nome di login, il terminale (tty), l'host remoto, l'ora di login, il tempo di inattività (idle), il tempo di CPU (JCPU e PCPU) e il comando in esecuzione. È il comando più utile per una prima occhiata, perché ti dice anche cosa sta facendo ogni sessione. La sua pagina di manuale indica il file /var/run/utmp come fonte solo per i sistemi senza systemd.

who e users su 26.04 vengono da rust-coreutils, la riscrittura in Rust delle coreutils. who -H aggiunge l'intestazione delle colonne, -u mostra il tempo di inattività, -q conta gli utenti. users stampa solo i nomi. La sua pagina di manuale dice che legge /var/run/utmp se non gli passi un altro file. Tieni a mente questo dettaglio, serve più avanti.

loginctl parla direttamente con systemd-logind, il servizio che registra le sessioni di login. list-sessions elenca le sessioni attive, ognuna con un ID. Con quell'ID puoi chiedere i dettagli:

loginctl session-status 3
loginctl user-status mario

session-status mostra lo stato della sessione, seguito dalle ultime righe del journal che la riguardano. user-status fa lo stesso per un utente. Nell'output cerca l'host remoto e l'ora di inizio. Le sessioni arrivano a logind tramite il modulo PAM pam_systemd, quindi loginctl vede le sessioni anche quando /run/utmp è vuoto o assente.

Perché who resta vuoto su Ubuntu 26.04?

Il problema è noto e ha un numero: il bug Launchpad LP #2152801, "who produces no output on 26.04 LTS". È stato aperto il 16 maggio 2026 contro rust-coreutils 0.8.0-0ubuntu3, la versione presente al rilascio di 26.04, con importanza High. La correzione attiva in rust-coreutils la funzione feat_systemd_logind. Così who e pinky chiedono le sessioni a logind invece di leggere utmp.

La correzione è arrivata anche su 26.04. La versione 0.10.0-1ubuntu2~26.04.1 è pubblicata in resolute-updates dal 21 settembre 2026 (bug di aggiornamento LP #2166202), e il suo changelog dice che who e pinky ora funzionano. Controlla quale versione hai:

apt policy rust-coreutils

Se la riga Installed: mostra 0.8.0-0ubuntu3, il server non è aggiornato, e un who vuoto è il comportamento noto di quella versione. Aggiorna e riprova:

sudo apt update
sudo apt upgrade
apt policy rust-coreutils
who -a -H

Dopo l'aggiornamento Installed: deve mostrare 0.10.0-1ubuntu2~26.04.1 o una versione successiva. Se vuoi capire cos'altro è cambiato con la riscrittura in Rust, leggi le riscritture in Rust nel sistema base di Ubuntu. Per decidere quando portare un server di produzione su 26.04, c'è la guida su cosa cambia con Ubuntu 26.04.1 e quando aggiornare.

Perché /run/utmp non è più una fonte affidabile

Per decenni who, w e users hanno letto /run/utmp, un file binario con una riga per ogni sessione aperta. Il formato utmp però non è sicuro rispetto al problema dell'anno 2038 (Y2038), cioè il limite oltre il quale molti vecchi campi data non funzionano più.

Per questo Debian e Ubuntu compilano systemd senza il supporto utmp. Il file di build del pacchetto systemd di Ubuntu 26.04 (versione 259.5-0ubuntu3.4) contiene l'opzione -Dutmp=false, quindi systemd non scrive più utmp e wtmp. Il changelog del pacchetto motiva la scelta così: "utmp is not y2038-safe". Debian ha disattivato utmp nella versione 256.5-2 (1 settembre 2024). Lo ha riattivato in 256.6-1 perché serviva a un test di tmux, e lo ha disattivato di nuovo in 256.7-2 (18 ottobre 2024). Ubuntu lo ha tenuto ancora per il ciclo di 24.10.

Un commento sul bug LP #2152801 dice che "systemd ha eliminato utmp nella versione 256". È impreciso. Si tratta di una scelta di pacchettizzazione di Debian e Ubuntu. Il progetto systemd ha ancora l'opzione di build utmp, e nelle parti delle note di rilascio di systemd che ho letto la versione 256 non annuncia nessuna rimozione. Le note della 255 dicono invece che i messaggi wall funzionano anche senza utmp, perché chiedono le informazioni a logind.

Puoi controllare tu stesso se il file esiste:

ls -l /run/utmp

Se il file manca o non viene aggiornato, ogni strumento che legge solo utmp non ha dati da mostrare. Per questo, su 26.04, la fonte di verità per le sessioni aperte è loginctl.

Chi si è collegato prima: last e wtmpdb

Su Ubuntu 26.04 last non viene più da util-linux. Lo fornisce il pacchetto wtmpdb (versione 0.75.0-5ubuntu1), che salva lo storico dei login in un database SQLite, /var/log/wtmp.db. La pagina di manuale dice che questo formato è sicuro rispetto al 2038. Prima verifica che il comando ci sia e da dove arriva:

command -v last
dpkg -S "$(command -v last)"

Se dpkg -S risponde wtmpdb: /usr/bin/last, sei a posto. Se command -v last non stampa nulla, il pacchetto manca. wtmpdb e il suo modulo PAM sono nel componente universe, e il pacchetto si limita a raccomandare il modulo. Installali insieme:

sudo apt install wtmpdb libpam-wtmpdb

Il modulo pam_wtmpdb registra login e logout. Su Ubuntu è lui che registra gli accessi SSH, perché openssh-server è compilato senza il supporto diretto a wtmpdb. Fino a dicembre 2025 la configurazione PAM di wtmpdb saltava le sessioni sshd, quindi gli accessi SSH non venivano registrati affatto (bug LP #2130851). La versione 0.75.0-5ubuntu1 ha tolto quell'esclusione. Il file README.Debian del pacchetto parla ancora di skip_if=sshd: su Ubuntu quel paragrafo non vale, non seguirlo.

Ora leggi lo storico:

last -n 20 -w -F
last -s yesterday
last -s "2026-10-01" -t "2026-10-08"
last -p "2026-10-15 03:00"
last reboot
last -x

-n 20 mostra le ultime 20 righe. -w stampa indirizzi IP e nomi completi, senza tagliarli. -F stampa data e ora complete. -s e -t limitano l'intervallo, e accettano formati come YYYY-MM-DD, YYYY-MM-DD HH:MM, today e yesterday. -p risponde a una domanda precisa: chi era presente a quell'ora. last reboot usa l'utente speciale reboot, i cui login e logout sono gli avvii e gli spegnimenti del sistema. -x aggiunge le righe di spegnimento.

Il last di wtmpdb non legge il vecchio formato utmp. All'installazione il pacchetto converte un /var/log/wtmp esistente, ma i file ruotati come /var/log/wtmp.1 restano nel vecchio formato. Per includerli usa sudo wtmpdb import /var/log/wtmp.1.

Dove sono finiti lastb e lastlog?

lastb mostrava i login falliti. Non esiste più. Le note di util-linux per Debian dicono: "lastb(1) is removed. Please see syslog/journal for failed login attempts." Nell'indice dei pacchetti di Ubuntu 26.04 nessun pacchetto contiene un file chiamato lastb. I tentativi falliti si leggono nei log di sshd, come mostra la prossima sezione.

Anche il classico lastlog, che mostrava l'ultimo login di ogni utente, non è nell'indice di 26.04. Il sostituto è lastlog2, che legge /var/lib/lastlog/lastlog2.db. Il database lo scrive un modulo PAM, nel pacchetto libpam-lastlog2. Entrambi sono in universe:

sudo apt install lastlog2 libpam-lastlog2
lastlog2 -a
lastlog2 -u mario
lastlog2 -t 7

-a nasconde gli utenti che non hanno mai fatto login. -u mostra un solo utente. -t 7 mostra solo i login degli ultimi 7 giorni. Senza opzioni, lastlog2 stampa nome, ora dell'ultimo login, tty e host remoto per tutti gli utenti presenti sul sistema. Dopo l'installazione esci, rientra via SSH e lancia lastlog2 -a. Se la tua riga non compare, il modulo PAM non è attivo e il database resta vuoto.

I log di sshd: la fonte che funziona sempre

Qualunque cosa mostrino who e last, sshd scrive ogni autenticazione nel journal. Su Ubuntu 26.04 sshd parte tramite socket activation (ssh.socket ascolta sulla porta 22), e l'unità da leggere è ssh.service. È la stessa che usa la documentazione ufficiale di Ubuntu.

sudo journalctl -u ssh.service -S today -g 'Accepted' --no-pager
sudo journalctl -u ssh.service -S "2026-10-01" -U "2026-10-08" -g 'Accepted' --no-pager
sudo journalctl -u ssh.service -n 50 -r

-S e -U fissano l'inizio e la fine dell'intervallo. -g filtra con un'espressione regolare sul testo del messaggio. -r mette in alto le righe più recenti. Nel codice sorgente di OpenSSH 10.2 le righe hanno questa forma:

Accepted <metodo> for <utente> from <IP> port <porta> ssh2
Failed <metodo> for <utente> from <IP> port <porta> ssh2
Failed <metodo> for invalid user <utente> from <IP> port <porta> ssh2
Invalid user <nome> from <IP> port <porta>

<metodo> è per esempio publickey o password. Un login riuscito con password, su un server dove usi solo chiavi, è già un segnale da approfondire. invalid user significa che il nome utente non esiste sul server. È il segno tipico di un bot che prova nomi a caso.

Per vedere quali IP ci provano più spesso, conta i tentativi falliti:

sudo journalctl -u ssh.service -S today -g 'Failed|Invalid user' --no-pager \
  | grep -oE 'from [0-9a-fA-F.:]+' | sort | uniq -c | sort -rn | head

Se sul server gira rsyslog, le stesse righe finiscono anche in /var/log/auth.log, perché la configurazione predefinita di Ubuntu manda lì i messaggi auth e authpriv. Non ho potuto confermare che rsyslog sia installato su ogni immagine VPS di 26.04, quindi controlla con ls /var/log/auth.log. Se il file c'è:

sudo grep -E 'Accepted|Failed|Invalid user' /var/log/auth.log | tail -n 30

Il journal funziona in entrambi i casi, quindi è la fonte da usare negli script.

Leggi prima l'IP e l'ora

Per ogni login che trovi, fatti due domande. La prima riguarda l'IP: lo riconosci? Confrontalo con l'IP pubblico della tua connessione di casa o dell'ufficio, e con quello dei server che amministrano questo host. L'opzione UseDNS di sshd vale no per impostazione predefinita, quindi nei log trovi indirizzi IP e non nomi host. È un vantaggio, perché un nome host lo decide chi gestisce il DNS, mentre l'IP è quello da cui è arrivata davvero la connessione.

La seconda domanda riguarda l'ora: eri al computer in quel momento? Qui l'errore più comune è il fuso orario. last e journalctl mostrano l'ora nel fuso del server. Se il server usa UTC e tu ragioni in ora italiana, la differenza è di un'ora in inverno (CET) e di due in estate (CEST). Controlla il fuso del server con:

timedatectl

Un accesso alle 03:12 UTC in agosto corrisponde alle 05:12 ora italiana. Se leggi l'ora senza questa correzione, puoi scambiare un tuo accesso per quello di un estraneo, o il contrario.

Le sessioni che questi comandi potrebbero non mostrare

Alcune sessioni possono mancare da who, w o last. Non ho una fonte che dica come si comporta 26.04 in ogni caso, quindi verifica sul tuo server.

I pannelli di tmux e screen. tmux scrive una riga in utmp solo se è compilato con la libreria utempter, e il pacchetto tmux di 26.04 non dipende da libutempter0. screen scrive una riga per finestra solo se può scrivere /run/utmp ed è compilato con il supporto utmp. Per controllare, apri un pannello e lancia who -a -H e loginctl list-sessions da un'altra finestra. Se usi tmux per tenere vivi i processi, la guida su come tenere un comando attivo dopo la disconnessione SSH spiega anche le alternative.

Le sessioni sftp e scp. La pagina di manuale di sshd dice che il login viene registrato "if the login is on a tty", e una sessione sftp di solito non ha un tty. Anche la configurazione PAM di wtmpdb è marcata Session-Interactive-Only: yes. Per sapere cosa succede sul tuo server, apri una sessione con sftp da un altro computer, poi lancia loginctl list-sessions e last -n 5. La riga Accepted nel journal di ssh.service resta comunque la prova più diretta, perché sshd registra l'autenticazione prima di aprire la sessione.

Quanto conservare lo storico degli accessi

Se il server tratta dati personali per un'azienda italiana, probabilmente conosci il provvedimento del Garante privacy del 27 novembre 2008 sugli amministratori di sistema, modificato il 25 giugno 2009. Chiede di registrare gli accessi logici degli amministratori ai sistemi, con "i riferimenti temporali e la descrizione dell'evento". Chiede di conservare queste registrazioni "per un congruo periodo, non inferiore a sei mesi", e che siano complete e inalterabili. Verifica con il tuo DPO se e come si applica al tuo caso.

Un punto tecnico vale comunque. /var/log/wtmp.db, il journal e auth.log stanno sullo stesso server che vuoi controllare, e chi ottiene i permessi di root li può modificare. Una copia regolare fuori dalla macchina è l'unico storico di cui ti puoi fidare dopo un'intrusione. Controlla quanto spazio occupa il journal e quali file di wtmpdb hai:

journalctl --disk-usage
ls -l /var/log/wtmp*

wtmpdb rotate esporta le righe più vecchie di 60 giorni (il valore predefinito) in file separati, con la data nel nome, dentro /var/log. Includili nella copia, altrimenti lo storico più vecchio resta solo sul server.

Cosa fare se trovi un login che non riconosci

Un login riuscito da un IP sconosciuto, in un orario in cui non lavoravi, va trattato come un incidente finché non trovi una spiegazione. Non cancellare nulla e non riavviare. Segui i passi di cosa fare se la tua VPS è stata violata, che partono proprio dal conservare le prove.

Un muro di righe Failed e Invalid user da IP sempre diversi è invece il rumore normale di un server esposto su internet. Non è un'intrusione, ma rende i log difficili da leggere. Il rimedio è configurare fail2ban per bloccare i tentativi su SSH, insieme alle impostazioni di hardening di SSH su una VPS, come disattivare il login con password.

Questa guida dice quando un utente è entrato e da dove. Non dice cosa ha fatto una volta dentro. Per quello serve la registrazione dei comandi eseguiti dagli utenti sul server.

FAQ

Perché il comando who non mostra nulla su Ubuntu 26.04?

È il bug LP #2152801 di rust-coreutils 0.8.0-0ubuntu3, la versione del rilascio iniziale di 26.04. Quella versione cerca le sessioni in utmp, e su Ubuntu systemd è compilato senza utmp, quindi non trova nulla. La versione 0.10.0-1ubuntu2~26.04.1 in resolute-updates chiede le sessioni a systemd-logind. Controlla con apt policy rust-coreutils e aggiorna con sudo apt update && sudo apt upgrade. Nel frattempo loginctl list-sessions mostra le sessioni aperte.

Come vedo i tentativi di login SSH falliti senza lastb?

lastb è stato rimosso da util-linux e non c'è su Ubuntu 26.04. Leggi i log di sshd con sudo journalctl -u ssh.service -S today -g 'Failed|Invalid user'. Ogni riga contiene l'utente provato, l'IP di provenienza e la porta. Se rsyslog è installato, le stesse righe sono anche in /var/log/auth.log.

Il comando last non esiste sul mio server. Cosa installo?

Su Ubuntu 26.04 last è nel pacchetto wtmpdb, nel componente universe. Lancia sudo apt install wtmpdb libpam-wtmpdb. Il secondo pacchetto è il modulo PAM che registra login e logout, compresi quelli SSH. Lo storico parte dall'installazione, più l'eventuale vecchio /var/log/wtmp che il pacchetto converte. Verifica con dpkg -S "$(command -v last)", che deve rispondere wtmpdb.

Qual è la differenza tra loginctl e who?

loginctl chiede le sessioni direttamente a systemd-logind, che le riceve dal modulo PAM pam_systemd a ogni login. who tradizionalmente leggeva il file /run/utmp, che su Ubuntu systemd non scrive più. Su un server aggiornato anche il who di rust-coreutils interroga logind. loginctl però resta la fonte diretta e funziona con ogni versione di rust-coreutils.