Indice della guida
Un Raspberry Pi che avvia AROS non diventa automaticamente una macchina facile da amministrare dal PC. Per copiare un archivio, controllare una versione o lanciare un comando senza tornare alla tastiera del Pi serve un collegamento che regga anche fuori dalla prima dimostrazione. BebboSSH AROS 1.0.5 aggiunge il pacchetto aarch64 e lavora proprio su questi dettagli: la conferma della chiave host, i tasti della console e l’uscita pulita del server.
Il punto da chiarire subito è il sistema operativo: questi binari sono per AROS sul Raspberry Pi, non per Raspberry Pi OS o per una distribuzione Linux ARM. Il progetto originale è BebboSSH di Stefan “Bebbo” Franke; il fork AROS è curato da Michele Dipace. La versione upstream 1.45 e la numerazione 1.0.5 del port non sono due aggiornamenti della stessa linea di pacchetti.
La novità sul Pi, senza confondere i tre pacchetti
Il codice è condiviso, ma i kit non sono intercambiabili. La build aarch64 usa le crosstool aarch64-aros e il sysroot del port raspi-aarch64. La verifica su hardware riportata nella documentazione riguarda un Raspberry Pi 400, con AROS del 12 settembre 2026, Ethernet e DHCP. Non basta che una scheda abbia una CPU ARM a 64 bit per dichiararla supportata.
| Kit | Destinazione e stato dichiarato | Esecuzione dei comandi remoti |
|---|---|---|
| i386, alt-abiv0 | AROS One a 32 bit; stabile nella 1.0.5 | ssh host comando usa un task figlio |
| x86_64, mincrt | AROS a 64 bit; stabile nella 1.0.5 | Sincrona: un comando lungo tiene occupato il daemon |
| aarch64, raspi-aarch64 | Prima release per AROS sul Pi; verificata sul Pi 400 | Segue il percorso i386, con task figlio per l’exec remoto |
In ogni kit ci sono quattro eseguibili: bebbosshd riceve le connessioni, bebbossh è il client SSH, bebboscp copia i file e bebbosshkeygen genera le chiavi Ed25519. La crittografia è collegata staticamente: per il port AROS corrente non va cercata una libcryptossh.library separata, richiesta invece in altri contesti dell’upstream Amiga.
Le correzioni della 1.0.5 si vedono nell’uso quotidiano
Il client finalmente aspetta la risposta sulla chiave host
Al primo collegamento bebbossh e bebboscp chiedevano se accettare la chiave del server, ma potevano leggere come risposta la riga di comando rimasta nel buffer di input da RunCommand(). Il risultato era un failed to verify the host prima che l’utente potesse rispondere. La 1.0.5 ripulisce quell’input iniziale e lascia il tempo di dare la risposta.
Non è una rimozione del controllo di sicurezza: è una correzione del dialogo. La chiave va comunque verificata; un cambiamento inatteso su un host già conosciuto non va accettato alla cieca.
Frecce e caratteri non devono litigare per lo stesso pacchetto
Nella shell del daemon, Shift+Freccia sinistra poteva lasciare sullo schermo [1;2D invece di spostare il cursore. Inoltre, se la sequenza di una freccia e il carattere successivo arrivavano nello stesso pacchetto, quel carattere poteva andare perso. Il parser ora conserva entrambi. È il genere di difetto che pesa mentre si corregge un percorso o si incolla testo, anche se il login SSH funziona perfettamente.
Il client aarch64 corregge anche il riconoscimento della console: il codice distingue il FILE della libreria C dall’handle AmigaDOS restituito da Input(). Questo evita di trattare i tasti cursore come input grezzo nel caso documentato.
Su aarch64 anche chiudere il server è parte del port
La release corregge la gestione della richiesta al timer e delle risorse della tastiera. Sul target aarch64 alcune chiamate si legavano alle allocazioni di amiga.lib, mentre la pulizia seguiva un percorso diverso: il daemon poteva funzionare e poi andare in crash all’uscita. Le coppie di chiamate Exec allineano creazione e rilascio delle risorse. Avviare, interrompere e riavviare il servizio è quindi un controllo concreto, non un dettaglio del packaging.
Che cosa è stato verificato, e su quale macchina
La checklist della release aarch64 riporta, sul Pi 400, i cinque self-test crittografici, 100 login consecutivi, trasferimenti SCP/SFTP nei due sensi e uno stress senza attesa fra le connessioni: 20 iterazioni, 80 trasferimenti fino a 1 MiB. Sono documentati anche i confronti byte per byte, la sovrascrittura con un file più corto, due daemon contemporanei, i client nativi e il riavvio dopo Break.
Questi sono risultati registrati dal progetto, non benchmark eseguiti durante la preparazione dell’articolo. Non dicono a quanti megabyte al secondo andrà la rete su qualunque Pi. Anche le vecchie misure sui processori 68k presenti nel README upstream non sono misure di questo port ARM.
La distinzione fra hardware e VM conta: nelle note aarch64, QEMU raspi3b con usb-net ha una ricezione molto lenta e un upload fallito, mentre gli stessi trasferimenti passano sul Pi 400. Usare quel risultato della VM come giudizio sulla rete della scheda reale sarebbe scorretto.
Prima installazione sul Raspberry Pi
Scarica il kit aarch64, estrailo e copia la directory sul volume AROS, per esempio SYS:BebboSSH. Configura prima la rete AROSTCP. Dalla Shell di AROS:
cd SYS:BebboSSH
copy sshd_config.example sshd_config
copy passwd.example passwd
ed passwd
ed sshd_config
bebbosshkeygen -f ssh_host_ed25519_key
stack 262144
bebbosshdIn sshd_config controlla anche la directory iniziale: l’esempio contiene HomeDir DH0:. Se sul Pi lavori su SYS:, impostala a un percorso esistente, per esempio HomeDir SYS:BebboSSH. Prima di avviare il daemon, nel file passwd sostituisci la credenziale dimostrativa con un utente e una password tuoi. Il formato bootstrap è una coppia username password per riga. La chiave host identifica questa installazione: va generata al primo setup, custodita e conservata durante gli aggiornamenti, non condivisa fra macchine.
Gli esempi usano percorsi PROGDIR:. Tieni dunque bebbosshd, sshd_config, passwd e la chiave nella stessa directory. Copiare il daemon in C: senza adeguare i percorsi significa fargli cercare lì anche la configurazione. I client possono invece essere copiati in C: per richiamarli più comodamente.
Sul volume FAT SYS: del Pi, protect può segnalare un errore: le note della release precisano che i binari restano eseguibili. Per l’avvio automatico, la checklist fornisce gli script e prevede AROSTCP al boot più una breve attesa prima del daemon. Meglio partire con il servizio avviato manualmente e passare all’autostart dopo avere verificato rete e login.
Dal PC: controllare una versione e spostare un file
Dal PC con OpenSSH puoi provare questi comandi, sostituendo IP_AROS con l’indirizzo del Pi e utente con l’account configurato:
ssh utente@IP_AROS Version
scp archivio.lha utente@IP_AROS:SYS:BebboSSH/
sftp utente@IP_AROSVersion è un buon primo comando breve; il trasferimento dell’archivio verifica un percorso scrivibile. Non c’è bisogno di trasformare subito la prova in una sessione con un editor a schermo intero. Puoi anche salvare l’output sul PC:
ssh utente@IP_AROS Version > versione-aros.txtQui la redirezione è eseguita dalla shell del PC. Non equivale a inviare Version > file alla shell remota di AROS, che non supporta ancora quelle redirezioni. Se il problema è una prima connessione del client nativo AROS, prova invece bebbossh utente@host dalla sua console: è proprio il percorso interessato dalla correzione della domanda sulla chiave.
I limiti da conoscere prima di usarlo per lavorare
- Non è una shell PTY completa. I comandi semplici sono supportati; programmi guidati dallo stdin e pipe o redirezioni remote vengono rifiutati con stato 2.
- Un comando digitato nella shell interattiva gira dentro il daemon: le altre connessioni aspettano e Ctrl-C non lo interrompe. Su i386 e aarch64 l’exec
ssh host comandousa un task figlio; su x86_64 resta sincrono. - Su i386 e aarch64, il timeout dopo 30 secondi con stato 124 non uccide il comando: il lavoro può continuare. Non va scambiato per una cancellazione riuscita.
- Sul Pi 400, i test riportano blocchi con log di debug
-v5in una console durante trasferimenti pesanti. Mantieni il livello predefinito e usa il debug per diagnosi brevi. - Su x86_64, un volume non montato può aprire un requester che blocca il daemon. Le opzioni per
cd, timestamp SFTP e link sono opt-in; non tutte hanno la stessa copertura di test. - La conservazione dei timestamp con OpenSSH
put -pha ancora un limite: la data impostata prima della chiusura può essere aggiornata da AROS alla chiusura del file.
I cifrari moderni non trasformano il sistema sottostante in un server Linux isolato e sottoposto ad audit. Le note del port documentano anche limiti del generatore casuale x86_64/mincrt, descritto come mixer best-effort e non come un vero CSPRNG. Per sperimentare il servizio parti da una rete controllata e non trattare il nome SSH come una garanzia sull’intera macchina.
Download della 1.0.5 e sorgenti corretti
| Target AROS | Release GitHub | Pacchetto Aminet |
|---|---|---|
| i386, alt-abiv0 | ZIP e tar.gz 1.0.5 | LHA i386 |
| x86_64, mincrt | ZIP e tar.gz 1.0.5 | LHA x86_64 |
| aarch64, Raspberry Pi | ZIP e tar.gz 1.0.5 | LHA aarch64 |
Le release includono i checksum per controllare l’integrità dei download; i tre ZIP pubblici corrispondono ai valori dichiarati. Anche le tre schede Aminet riportano 1.0.5: non sono soltanto rimandi al pacchetto originale 68k. Il repository pubblico del fork è su GitHub. La licenza è GPLv3 o successiva, con attribuzioni upstream e testi di licenza da conservare nelle redistribuzioni.
Il ramo di sviluppo è già oltre quei binari
Il commit del 13 ottobre aggiunge una protezione per i log di pacchetti DOS senza un canale shell associato: evita una dereferenziazione nulla prima ancora che il livello di log possa filtrare il messaggio. È una correzione successiva. I tre tag pubblici 1.0.5 puntano al commit 188e301, quindi quel fix non va attribuito ai ZIP della 1.0.5 già scaricabili.
È questa la lettura utile della release: un kit ARM concreto, piccoli difetti del client eliminati e confini operativi espliciti. Per la storia del port e il suo posto nel laboratorio, c’è il primo articolo BebboSSH AROS su RetroLab; per installare o compilare, le istruzioni versionate del repository restano il riferimento.