Indice della guida
BebboSSH AROS 1.0.6 è un aggiornamento di sicurezza e manutenzione disponibile dal 15 ottobre per i386 alt-abiv0, x86_64 con runtime mincrt e aarch64, il port di AROS per Raspberry Pi. Non aggiunge soltanto una voce al changelog: corregge il percorso di autenticazione, rende più rigorosi i controlli sulle chiavi host e risolve un difetto che poteva fermare gli upload SFTP e SCP a 2 MiB.
Il progetto deriva da BebboSSH di Stefan “Bebbo” Franke; il port AROS è mantenuto da Michele Dipace, che firma anche questo articolo. La 1.0.6 integra correzioni provenienti da bebbossh 1.46.1, la build non ufficiale di Matthias Münch. I due numeri identificano linee diverse: la release del fork AROS è 1.0.6, non 1.46.1.
Autenticazione: la richiesta di una chiave non è un login
La modifica più importante riguarda ciò che il server accetta prima dell’autenticazione. Il daemon ora ammette soltanto le richieste di servizio e di autenticazione previste in quella fase. Una semplice interrogazione sulla disponibilità di una chiave pubblica, priva di firma, non basta più a far risultare autenticato il client: per accedere serve la richiesta firmata.
Il parsing dei pacchetti, sia nel daemon sia nei client, viene limitato ai dati effettivamente ricevuti. Un pacchetto malformato chiude la sessione invece di lasciare proseguire l’elaborazione su lunghezze non valide. Anche attributi e scritture SFTP ricevono controlli sui limiti dei buffer.
- Corrette scritture fuori limite nel codice Ed25519 e in
bebbosshkeygen. - Rifiutate firme Ed25519 non canoniche, con parametro
S >= L. - Confronto dei tag di autenticazione a tempo costante e rifiuto di un segreto condiviso X25519 interamente nullo.
- Cancellazione del materiale crittografico dei client all’uscita.
- Ulteriori controlli del client sulla stringa di versione del server, sulla lunghezza del pacchetto e sulla dimensione massima dichiarata.
Sono correzioni concrete, non una certificazione generale di sicurezza del sistema AROS. Le note di rilascio raccomandano l’aggiornamento.
Chiavi host: cambia anche il comportamento degli script
bebbossh e bebboscp rifiutano un server la cui chiave non corrisponde a quella registrata in ENVARC:.ssh/known_hosts, mostrando un avviso. La correzione comprende anche l’ordine degli argomenti delle chiamate Seek() usate per quel file.
Un host sconosciuto viene proposto all’utente soltanto se il programma dispone di una console. Se il client gira senza console, per esempio dentro un comando remoto, la connessione viene rifiutata. Prima di inserire un nuovo server in un’automazione, bisogna quindi collegarsi da una Shell, verificare la chiave e accettarla consapevolmente. Una chiave cambiata non va liquidata come un fastidio da aggirare.
Arriva inoltre la direttiva AllowTcpForwarding in sshd_config. Il valore predefinito è yes; impostando no si rifiutano le richieste di forwarding direct-tcpip. Non serve cambiare i cifrari per usare questa impostazione.
Perché gli upload si fermavano a 2 MiB
All’apertura di un canale il daemon pubblicizzava come propria finestra di ricezione quella del client: con OpenSSH e Paramiko erano normalmente 2 MiB. La contabilità interna usava invece una finestra da 512 MiB, da aggiornare sotto i 256 MiB. Il mittente esauriva dunque il credito dopo 2 MiB, mentre il server non aveva motivo di inviare l’aggiornamento atteso: il trasferimento restava fermo.
La 1.0.6 annuncia la finestra che il daemon usa davvero. Le note riportano upload SFTP da 1 a 16 MiB, trasferimenti SCP e un upload da 4 MiB attraverso un canale direct-tcpip. Non è un aumento arbitrario della dimensione massima dei file, ma la correzione della gestione della finestra SSH. È incluso anche il fix che evita di dereferenziare un canale shell assente durante alcuni log di pacchetti DOS.
Raspberry Pi: ChaCha20 disponibile per impostazione predefinita
Su aarch64, in assenza di una direttiva Ciphers, il daemon offre ora chacha20-poly1305@openssh.com oltre a aes128-gcm@openssh.com. I client nativi bebbossh e bebboscp provano prima ChaCha20-Poly1305; configurazione e opzione --ciphers permettono ancora di scegliere l’ordine.
Su Raspberry Pi l’implementazione AES-GCM è in C portabile, senza istruzioni AES dedicate. Le prove documentate sul Pi 400 hanno però misurato tempi equivalenti con i due cifrari: non c’è motivo di trasformare questa novità in una promessa di accelerazione. Su i386 il default del daemon resta AES-GCM, salvo una riga Ciphers; x86_64 offriva già entrambi.
Download 1.0.6 e aggiornamento
I tre kit contengono server, client SSH, client SCP, generatore di chiavi, esempi di configurazione e licenze. I binari sono specifici per architettura e non intercambiabili. La crittografia è collegata staticamente: per questo port non occorre installare una libcryptossh.library separata.
| Target AROS | GitHub, ZIP e tar.gz | Aminet, LHA |
|---|---|---|
| i386 alt-abiv0 | Release i386 1.0.6 | Pacchetto i386 1.0.6 |
| x86_64 mincrt | Release x86_64 1.0.6 | Pacchetto x86_64 1.0.6 |
| aarch64, Raspberry Pi | Release aarch64 1.0.6 | Pacchetto aarch64 1.0.6 |
Per una prima installazione, il README del kit indica di copiare i file su un volume AROS, creare la configurazione dagli esempi, sostituire le credenziali dimostrative e generare una chiave host sulla macchina di destinazione. Per un aggiornamento, conservare la propria configurazione e la propria chiave host: ricrearla inutilmente provocherebbe proprio l’avviso di chiave cambiata sui client. Non distribuire chiavi private insieme ai pacchetti.
Quando si sostituisce il daemon tramite SCP/SFTP, le istruzioni del progetto raccomandano di eliminare il vecchio eseguibile prima di caricare quello nuovo e di riscaricarlo per un confronto byte per byte. Per l’avvio su Raspberry Pi, compresi rete AROSTCP e attesa iniziale, il riferimento resta la checklist aarch64 inclusa nell’archivio.
Prove documentate e limiti ancora presenti
Le release riportano prove su AROS One i386 e x86_64 sotto QEMU, quest’ultimo con scheda rtl8139, e su un Raspberry Pi 400 reale. Tra i risultati figurano 100 login consecutivi e 80 trasferimenti senza pausa, oltre ai controlli su autenticazione, chiavi host, trasferimenti e arresto del daemon. Sono risultati documentati dal progetto: per questo articolo sono stati verificati le fonti, i sei archivi GitHub e i relativi SHA-256, non ripetuti i test hardware.
- La shell PTY completa resta incompleta; pipe e redirezioni nei comandi remoti non sono supportate.
- I comandi digitati nella sessione interattiva occupano il daemon. Su i386 e aarch64,
ssh host comandousa invece un task separato; il timeout a 30 secondi restituisce stato 124 ma non termina il comando. - Su x86_64 anche l’exec remoto è sincrono. Un volume non montato può ancora aprire un requester e bloccare il daemon; alcune funzioni richiedono i flag opt-in descritti nel README.
- Su AROS One x86_64 il driver e1000 può provocare blocchi o riavvii sotto carico. Le note consigliano rtl8139 o pcnet finché non viene distribuito il driver corretto.
- Sul Pi 400 il logging
-v5in console durante trasferimenti pesanti ha provocato blocchi: mantenere il livello predefinito. - I timestamp impostati da OpenSSH
put -ppossono essere sovrascritti dalla chiusura del file su AROS.
Il nuovo pool di entropia è successivo alla release
Il ramo di sviluppo è già più avanti. Il commit del 16 ottobre introduce un pool basato su SHA-512, campioni temporali e un seed persistente in ENVARC:.ssh/random_seed, insieme ad altri interventi su bebbosshkeygen. È una modifica distinta: i tre tag pubblici 1.0.6 puntano a 33d0cd5, precedente a quel commit. Il nuovo pool non va quindi attribuito agli archivi 1.0.6 qui collegati.
Per chi usa già il port, l’aggiornamento ha una motivazione chiara anche senza quella modifica successiva: autenticazione più rigorosa, controlli del client corretti e trasferimenti che non si fermano alla prima finestra SSH. Il precedente articolo sulla 1.0.5 resta il riferimento per l’arrivo del kit Raspberry Pi e l’inquadramento del port.