On this page
BebboSSH AROS 1.0.6 is a security and maintenance update released on October 15 for i386 alt-abiv0, x86_64 with the mincrt runtime, and aarch64, the Raspberry Pi port of AROS. This is more than a version bump: it fixes the authentication path, tightens host key checks and resolves a defect that could stall SFTP and SCP uploads at 2 MiB.
The project derives from Stefan “Bebbo” Franke’s BebboSSH; the AROS port is maintained by Michele Dipace, who also writes this article. Version 1.0.6 incorporates fixes from bebbossh 1.46.1, Matthias Münch’s unofficial build. Those numbers belong to different release lines: the AROS fork release is 1.0.6, not 1.46.1.
Authentication: a public-key query is not a login
The most important change concerns what the server accepts before authentication. The daemon now accepts only the service and user-authentication requests appropriate to that stage. A public-key availability query without a signature no longer marks the client as authenticated: logging in requires the signed request.
Packet parsing in both the daemon and clients is bounded to the data actually received. A malformed packet closes the session rather than allowing processing to continue with invalid lengths. SFTP attributes and write requests also gain buffer bounds checks.
- Out-of-bounds writes in the Ed25519 code and
bebbosshkeygenare fixed. - Non-canonical Ed25519 signatures, with
S >= L, are rejected. - Authentication tags are compared in constant time, and an all-zero X25519 shared secret is refused.
- Clients wipe their key material on exit.
- The client adds checks on the server version string, packet length and declared maximum packet size.
These are concrete fixes, not a general security certification for AROS. The release notes recommend updating.
Host keys: scripts behave differently too
bebbossh and bebboscp refuse a server whose key differs from the one stored in ENVARC:.ssh/known_hosts, with a warning. The fix also corrects the argument order of the Seek() calls used for that file.
An unknown host is presented to the user only when the program has a console. If the client runs without one, for example inside a remote command, the connection is refused. Before adding a new server to an automation, connect from a Shell window, verify its key and deliberately accept it. A changed key should not be treated as a nuisance to bypass.
The update also adds AllowTcpForwarding to sshd_config. Its default is yes; setting it to no refuses direct-tcpip forwarding requests. Using this setting does not require changing the ciphers.
Why uploads stopped at 2 MiB
When opening a channel, the daemon advertised the client’s receive window as its own: normally 2 MiB with OpenSSH and Paramiko. Its internal accounting instead used a 512 MiB window, to be refreshed below 256 MiB. The sender therefore exhausted its credit after 2 MiB while the server had no reason to send the expected adjustment, leaving the transfer stalled.
Version 1.0.6 advertises the window the daemon actually tracks. The notes report SFTP uploads from 1 to 16 MiB, SCP transfers and a 4 MiB upload through a direct-tcpip channel. This is not an arbitrary increase in maximum file size, but a correction to SSH window handling. The update also includes the fix that avoids dereferencing a missing shell channel while logging some DOS packets.
Raspberry Pi: ChaCha20 available by default
On aarch64, without a Ciphers directive, the daemon now offers chacha20-poly1305@openssh.com alongside aes128-gcm@openssh.com. The native bebbossh and bebboscp clients try ChaCha20-Poly1305 first; configuration and the --ciphers option can still set the order.
On Raspberry Pi the AES-GCM implementation uses portable C, without dedicated AES instructions. However, the documented Pi 400 tests measured equivalent times with both ciphers: this change should not be turned into a performance promise. On i386 the daemon default remains AES-GCM unless a Ciphers line is present; x86_64 already offered both.
Version 1.0.6 downloads and updating
The three kits contain the server, SSH client, SCP client, key generator, configuration examples and licences. Their binaries are architecture-specific and are not interchangeable. Cryptography is statically linked: this port does not require a separate libcryptossh.library.
| AROS target | GitHub, ZIP and tar.gz | Aminet, LHA |
|---|---|---|
| i386 alt-abiv0 | i386 1.0.6 release | i386 1.0.6 package |
| x86_64 mincrt | x86_64 1.0.6 release | x86_64 1.0.6 package |
| aarch64, Raspberry Pi | aarch64 1.0.6 release | aarch64 1.0.6 package |
For a first installation, the kit README instructs users to copy the files to an AROS volume, create configuration files from the examples, replace the demonstration credentials and generate a host key on the destination machine. When updating, preserve your configuration and host key: unnecessarily replacing the key would trigger precisely the changed-key warning on clients. Never distribute private keys with packages.
When replacing the daemon over SCP/SFTP, the project instructions recommend deleting the old executable before uploading its replacement, then downloading it again for a byte-for-byte comparison. For Raspberry Pi startup, including AROSTCP networking and the initial delay, refer to the aarch64 checklist included in the archive.
Documented tests and remaining limits
The releases report tests on AROS One i386 and x86_64 under QEMU, the latter with an rtl8139 card, and on a real Raspberry Pi 400. Results include 100 consecutive logins and 80 zero-delay transfers, alongside checks on authentication, host keys, transfers and daemon shutdown. These are results documented by the project: this article’s checks covered the sources, six GitHub archives and their SHA-256 digests, not a fresh hardware test run.
- Full interactive PTY support remains incomplete; pipes and redirection in remote commands are unsupported.
- Commands typed in an interactive session occupy the daemon. On i386 and aarch64,
ssh host commandinstead uses a separate task; the 30-second timeout returns status 124 but does not terminate the command. - On x86_64 remote exec is synchronous too. An unmounted volume can still open a requester and block the daemon; some features require the opt-in flags described in the README.
- On AROS One x86_64 the e1000 driver can cause hangs or reboots under load. The notes recommend rtl8139 or pcnet until the corrected driver is distributed.
- On the Pi 400, console logging with
-v5during heavy transfers has caused hangs: keep the default logging level. - Timestamps set by OpenSSH
put -pmay be overwritten when AROS closes the file.
The new entropy pool comes after this release
The development branch has already moved ahead. The October 16 commit introduces a SHA-512-based pool, timing samples and a persistent seed at ENVARC:.ssh/random_seed, alongside further bebbosshkeygen changes. This is a separate change: all three public 1.0.6 tags point to 33d0cd5, which predates that commit. The new pool must therefore not be attributed to the 1.0.6 archives linked here.
For existing users, the update has a clear purpose even without that later change: stricter authentication, corrected client checks and transfers that do not stall at the first SSH window. The previous article on version 1.0.5 remains the reference for the arrival of the Raspberry Pi kit and the port’s background.