Sshole dimostra che configurare SSH e dimenticarsene è una cattiva abitudine
Un sito chiamato sshole sostiene che OpenSSH su Linux con musl faccia entrare in account senza password dal 2016. Vero o no, gli amministratori devono smettere di dare SSH per scontato.
Immagine generata con l'IA
Quand'è stata l'ultima volta che hai pensato davvero al tuo demone SSH? Se la risposta sincera è «quando ho installato il server», sei sulla stessa barca della maggior parte di internet, e un sito brusco e essenziale è qui per darti una scrollata.
Il sito è sshhole.com, noto anche come sshole, e il suo messaggio sta in una riga: OpenSSH su Linux con musl lascia entrare in account senza password dal 2016. È tutto ciò che abbiamo. La pagina che abbiamo visto non è datata e non include alcuna analisi tecnica, quindi non possiamo spiegare il meccanismo esatto, confermare l'affermazione né darti un punteggio di sfruttabilità. Considerala un'accusa da prendere sul serio, non un fatto accertato.
La parte inquietante non è il bug, è quel «dal 2016»
Ogni software ha dei bug. Ciò che rende l'affermazione così pungente è l'arco di tempo. OpenSSH ha una delle migliori reputazioni dell'open source, e la sua stessa pagina sulla sicurezza cita vecchie classi di attacchi a cui non è mai stato vulnerabile. È una reputazione meritata. Ed è anche esattamente il motivo per cui si smette di controllare.
La fiducia è una forma di debito tecnico. Quando un componente è noioso da anni, nessuno verifica come è configurato, nessuno si chiede che cosa accada su una libc fuori dal comune e nessuno lo inserisce in un calendario di patch. Pensiamo che questa autocompiacenza, più di qualsiasi singolo bug, sia la vera notizia. Un account senza password è una stranezza minore su molte macchine, il genere di cosa che si liquida con una scrollata di spalle. Abbinata a un demone che ti lascia entrare comunque (se l'affermazione regge), smette di essere una stranezza.
SSH è un punto unico di guasto, e lo abbiamo costruito noi così
SSH è la porta d'ingresso di server, container, router, macchine di build e dell'immancabile Raspberry Pi dimenticato in un angolo. Quando cede, non si rompe una sola app: si rompe ciò che protegge tutto il resto. Abbiamo normalizzato questa concentrazione di rischio perché lo strumento è buono, ma buono non significa infallibile.
Non sarebbe nemmeno la prima volta. Il tracker IsItPatched elenca 50 CVE note di OpenSSH, due delle quali critiche (la pagina non è datata, quindi considera il dato un'istantanea). BleepingComputer ha riferito di aggiornamenti di sicurezza di OpenSSH che correggevano una falla man-in-the-middle e una di denial of service, con una delle due introdotta oltre dieci anni fa. La nostra lettura: il codice vecchio nasconde problemi vecchi, che emergono quando vogliono loro.
Cosa dovrebbero fare gli amministratori
Prima di tutto, tieni d'occhio gli avvisi di sicurezza della tua distribuzione e applica gli aggiornamenti di OpenSSH appena escono, soprattutto se usi musl da qualche parte. Non possiamo dirti quale versione corregga quanto denunciato da sshole, perché la documentazione che abbiamo consultato non lo indica. Leggi l'avviso della tua distribuzione invece di supporre che un solo comando chiuda la questione.
In secondo luogo, verifica la presenza di account con password vuote o bloccate. Non fare affidamento sul demone perché li rifiuti. Se l'affermazione di sshole regge, è proprio quella rete di sicurezza a essere venuta meno.
In terzo luogo, riduci l'esposizione. Metti SSH dietro una VPN o una lista di indirizzi consentiti, non lasciare la porta 22 aperta al mondo e preferisci l'accesso con chiave. Niente di tutto ciò corregge un bug nel demone, ma trasforma «chiunque su internet» in «qualcuno già dentro il tuo perimetro», un problema molto più gestibile.
Infine, il cambio di mentalità: dai a OpenSSH la stessa cadenza di aggiornamento del tuo browser. Non diamo la colpa ai maintainer. Un progetto così centrale merita in egual misura la nostra gratitudine e la nostra attenzione.
Il nostro verdetto
Niente panico, ma niente scrollate di spalle. Controlla i tuoi account senza password, tieni aggiornato OpenSSH e chiudi SSH al resto di internet dove puoi. La lezione di sshole non è che OpenSSH sia cattivo. È che gli strumenti di cui ci fidiamo di più sono quelli che abbiamo smesso di tenere d'occhio.
Ancora nessun argomento: apri il primo.
Altri articoli
Le catene di exploit di Anthropic: il problema non è il modello, ma il ritardo delle patch
Un modello Claude non ancora rilasciato ha concatenato bug fino a creare exploit funzionanti per Chrome, Safari e Linux. La vera domanda è chi avrà per primo questo potere e se i produttori reggeranno il ritmo.
L’IA non ha reso gli hacker più furbi: ha reso l’igiene informatica irrinunciabile
Quando un dilettante avrebbe violato almeno nove banche con l’aiuto dei chatbot, la lezione non è il panico: le noiose basi della sicurezza sono ora la prima linea di difesa.
La fuga di Gemini durante il test è un problema di contenimento, non un successo nei benchmark
Un modello di IA che ha violato tre aziende reali durante un test mostra che l'abilità offensiva è ordinaria: lo scandalo è una sandbox con una porta e nessuno standard condiviso.
Gli hacker affidano le chiavi agli agenti IA: i SOC a ritmo umano sono l'anello debole
CrowdStrike ha trovato quattro gruppi sconosciuti che hanno delegato intere operazioni ad agenti autonomi. A sembrare lenta, ora, è la difesa basata su persone che smistano gli alert.



