AndroidLab Dal retrocomputing all'AI, passando per Android.

BebboSSH AROS 1.0.7: login PuTTY e sicurezza

di
BebboSSH AROS 1.0.7: login PuTTY e sicurezza
Indice della guida

BebboSSH AROS 1.0.7, pubblicato il 19 ottobre 2026, corregge una regressione che impediva il login con password da PuTTY e dai client della stessa famiglia. La release aggiorna tutte e tre le varianti AROS, i386, x86_64 e aarch64, e affianca alla compatibilità una serie di controlli su pacchetti SSH, richieste SFTP, forwarding e generazione delle chiavi.

Il fork AROS mantiene il credito al progetto originale di Stefan “Bebbo” Franke; il porting di Michele Dipace è distribuito con licenza GPL v3 o successiva. La numerazione 1.0.7 identifica il port AROS, non una nuova versione numerata allo stesso modo dell’upstream, la cui base qui è BebboSSH 1.45. Il pacchetto comprende server bebbosshd, client bebbossh, client SCP bebboscp e generatore Ed25519 bebbosshkeygen.

Perché PuTTY e WinSCP non entravano con la password

La 1.0.6 aveva rafforzato l’autenticazione e corretto gli upload, ma chiudeva la connessione se il client inviava SSH_MSG_IGNORE prima del login. PuTTY, plink, pscp, psftp e WinSCP lo inviano prima della password: il collegamento poteva quindi interrompersi senza che la password fosse il problema.

La 1.0.7 gestisce nuovamente prima dell’autenticazione i messaggi IGNORE, DEBUG, UNIMPLEMENTED e DISCONNECT. Non significa riaprire l’accesso ai canali prima del login: le note riportano verifiche che un canale preautenticazione venga rifiutato e che una semplice interrogazione su una chiave pubblica non autentichi l’utente.

Anche dopo il login, SSH_MSG_DISCONNECT termina ora la sessione senza aspettare la chiusura della connessione. Su x86_64 un comando già in esecuzione mantiene però il limite del backend sincrono: la gestione prosegue quando quel comando termina, non viene promessa un’interruzione immediata del processo.

Il pool di entropia entra nei pacchetti pubblicati

Nell’articolo della 1.0.6 il pool era stato descritto correttamente come lavoro successivo alla release. Con la 1.0.7 è incluso nei pacchetti: usa SHA-512 per mescolare jitter del timer CPU, risvegli di timer.device, contatori di sistema e un seed persistente di 64 byte in ENVARC:.ssh/random_seed, sostituito da ciascun programma al primo utilizzo.

Il lavoro deriva dalla patch 0008 di BebboSSH 1.46.1 di Matthias Münch, con attribuzione esplicita, senza implicare che l’intero fork sia stato ribasato a quella versione. Su QEMU senza virtualizzazione hardware, il generatore avvisa quando il timer CPU mostra poco jitter: in quella situazione pesano maggiormente risvegli del timer e seed. Non è una ragione per distribuire immagini clonate con lo stesso seed.

Ogni macchina deve avere il proprio seed. Il manuale raccomanda, prima della chiave host definitiva, di far creare il seed a una chiave usa e getta con bebbosshkeygen -f T:seed_key e rimuovere poi quella coppia temporanea. Il miglioramento della raccolta non equivale alla presenza garantita di un CSPRNG di sistema su ogni configurazione AROS.

Controlli SFTP e SSH prima di usare i dati ricevuti

Le richieste SFTP vengono limitate fra 5 byte e 256 KiB. Stringhe e campi successivi devono rientrare nella richiesta; una richiesta malformata chiude il canale SFTP. Le prove documentate includono OPEN senza i flag previsti, CLOSE con handle vuoto e lunghezze impossibili, verificando che il daemon continui poi a servire altre richieste.

Il login con chiave pubblica costruisce chiave e dati firmati in buffer propri, non nello spazio dietro il pacchetto ricevuto. Una richiesta firmata oltre 1 KiB viene rifiutata. Dal lato client vengono controllati padding dei pacchetti non cifrati, lunghezze delle liste KEXINIT e pacchetti di canale troppo corti. Sono controlli di validità e limiti, non l’annuncio di nuovi algoritmi crittografici.

Il forwarding locale -L rispetta il massimo pacchetto del canale e legge al più un pacchetto alla volta: nella 1.0.6 una raffica più grande poteva corrompere i dati inoltrati. Anche AllowTcpForwarding cambia in modo conservativo: no, remote, false, off, 0 e valori sconosciuti rifiutano il forwarding. In particolare off prima non lo disabilitava.

Chiavi, errori e correzioni specifiche delle architetture

  • bebbosshkeygen controlla le scritture ed elimina una chiave privata rimasta parziale. Restituisce 10 per quel fallimento, oppure 5 se fallisce solo il file pubblico .pub, e ripulisce i propri segreti; anche AES e ChaCha20 azzerano lo stato della chiave.
  • bebbossh e bebboscp restituiscono un errore ERROR_START, valore 29, quando il server rifiuta comando, shell, terminale o sottosistema SFTP. Vale anche per un file sorgente locale mancante in bebboscp: prima questi casi potevano apparire riusciti con uscita 0.
  • Una nuova chiave aggiunta a known_hosts inizia sempre su una riga propria, anche se il file precedente non terminava con un a capo.
  • Su i386 viene corretta la liberazione della richiesta al timer all’uscita del daemon: la chiamata errata poteva danneggiare la lista della memoria di sistema.
  • Su i386 e aarch64, il generatore non interpreta più la riga di comando come prima risposta: sulla console mostra le domande e attende l’utente; l’input rediretto viene letto normalmente.

Nel codice x86_64 mincrt è corretta anche realloc quando non riesce ad allocare il nuovo blocco: conserva il blocco originale, che rimane di proprietà del chiamante. È un comportamento richiesto dal contratto C, distinto dalle funzionalità SSH visibili all’utente.

Tre versioni, limiti diversi

i386 alt-abiv0: niente shell PTY completa, redirezioni o pipe. Un comando digitato nella sessione interattiva occupa il daemon fino alla fine; per i comandi lunghi è preferibile ssh host comando, eseguito in una task separata. Dopo 30 secondi un comando remoto ancora attivo può ricevere segnalazione di timeout e stato 124, ma il processo non viene fermato: una chiusura del daemon attende che finisca. Senza una direttiva Ciphers, il server i386 offre solo AES128-GCM.

x86_64 mincrt: l’esecuzione dei comandi resta sincrona, anche fuori dalla shell interattiva. Un comando lungo blocca il ciclo del daemon e Ctrl-C non lo interrompe: usare comandi brevi. Un percorso SFTP su un volume non montato apre ancora il requester locale e blocca il servizio finché non viene chiuso. HomeDir, conservazione mtime e link SFTP dipendono dai flag opzionali documentati BEBBOSSH_AROS_X64_CD, BEBBOSSH_AROS_X64_SFTP_MTIME e BEBBOSSH_AROS_X64_SFTP_LINKS, disattivi se non impostati.

Le note x86_64 segnalano inoltre arresti o riavvii di AROS One sotto carico con il driver e1000. La correzione è indicata nell’issue upstream AROS 274; finché l’immagine utilizzata non la include, le note raccomandano rtl8139 o pcnet. Non è una correzione del driver contenuta in BebboSSH.

aarch64 Raspberry Pi: valgono i limiti della shell indicati per i386. Sul Pi 400 il debug -v5 verso una finestra console durante trasferimenti pesanti ha congelato il sistema nelle prove documentate: mantenere il livello di log predefinito. Su SYS: FAT un errore di protect va interpretato secondo il manuale, non come dimostrazione che il trasferimento non sia riuscito.

In tutte le varianti, OpenSSH put -p può perdere l’orario richiesto perché AROS aggiorna la data alla chiusura. Il file passwd di esempio contiene credenziali di test: cambiarle prima di esporre il daemon. I pacchetti delle tre architetture non sono intercambiabili.

Prove documentate e controlli fatti per questo articolo

Le note riportano 100 login riusciti su 100 e stress senza pausa fra connessioni superato 80 volte su 80 sulle tre architetture, upload SFTP da 1 a 16 MiB e trasferimenti attraverso direct-tcpip. Descrivono inoltre autenticazione OpenSSH con chiave, casi IGNORE/DEBUG prima della password, richieste malformate, disconnessioni, ripartenza del daemon e client nativi.

Su x86_64 le prove coprono QEMU sia con CPU generica sia con AES-NI/PCLMUL; su i386 l’uscita del daemon comprende anche i comandi ancora attivi. Per aarch64 la piattaforma dichiarata è un Raspberry Pi 400, AROS del 12 settembre 2026, Ethernet e DHCP. I sei self-test della stessa build sono riportati per i386 e ARM64, non come test eseguiti sul Mac per questa pubblicazione.

I controlli effettuati oggi riguardano invece sorgenti e pacchetti: note delle tre release, differenze rispetto alla 1.0.6, sei archivi GitHub con SHA-256 corrispondenti e integrità ZIP o tar.gz verificata. Aminet riporta 1.0.7 per le tre varianti. Non sono stati inventati nuovi test sul Pi o sulle VM. I tag della release puntano al codice preparato per la 1.0.7; il commit successivo aggiorna soltanto i valori predefiniti degli script di smoke test.

Download ufficiali

Seguire il README.AROS.txt incluso nell’archivio per installazione, chiavi e configurazione, preservando i propri file privati durante l’aggiornamento. Usare il pacchetto dell’architettura corretta e ripetere i controlli di accesso e trasferimento prima di affidargli un servizio remoto.

Fonti

AUTORE

Informatico, sviluppatore e sistemista con una lunga storia tra codice, server Linux, retrocomputer e piattaforme e-learning. Su AndroidLab porta uno sguardo tecnico e pragmatico: meno fumo da brochure, più attenzione a infrastruttura, usabilità, privacy, aggiornamenti e conseguenze concrete delle scelte dei produttori.

Lascia un commento