The aarch64 work in BebboSSH AROS 1.0.5 is a useful case study. The difficult parts were not all in the protocol code: a host-key question consumed the wrong input, a console check received the wrong kind of handle, and cleanup crossed allocation boundaries.

I maintain the AROS fork of Stefan "Bebbo" Franke's BebboSSH. This article examines the versioned source and release checklist, rather than presenting new benchmarks. The target is AROS running on a Raspberry Pi, not Raspberry Pi OS or another Linux distribution. The documented hardware validation is on a Pi 400; it is not evidence that every ARM board works.

1. Same source tree does not mean the same runtime

The fork shares source across three public targets:

These differences affect behavior after compilation. On x86_64, a long remote command can occupy the daemon. On i386 and aarch64, the child-task backend allows it to remain responsive. The binaries and their release kits are not interchangeable.

The cryptography also has a packaging difference from the classic Amiga build. The AROS tools link the inherited crypto code statically, rather than requiring a separately installed libcryptossh.library. That avoids one executable/library version mismatch, but increases the amount of code embedded in each tool.

2. A host-key failure can start before the user answers

Before 1.0.5, the native client could print the first-connection host-key question and then fail with failed to verify the host before the user had a chance to respond.

The relevant boundary was AmigaDOS command startup. RunCommand() leaves command-line input available in Input() for argument processing. The key-confirmation path could consume those leftover bytes as the answer.

The release adds an input flush in the AROS startup path:

// Drop command-line input left for ReadArgs().
Flush(Input());

This is an abbreviated excerpt, not a complete portable SSH initialization routine. The x86_64 minimal runtime also needed a compatible wrapper.

The important distinction is that the fix restores the conversation with the user. It does not remove host-key verification. An unexpected key change still needs investigation.

When a prompt appears to answer itself, inspect where its input stream came from before changing the validation logic.

3. A C stream and an operating-system handle are different things

Another client issue involved console detection. In this AROS environment, stdin is the C library's FILE object. IsInteractive() expects an AmigaDOS file handle.

The AROS branch now asks about the handle returned by Input():

escape = IsInteractive(Input());

The distinction matters even when a compiler lets an inappropriate value reach an API. The old console check caused raw cursor-key handling on aarch64 in the documented case.

This is an easy mistake to make when porting a program that already supports several environments. Familiar names such as standard input can hide incompatible representations. Follow the ownership and type expectations of the receiving API, not just the name of the object being passed.

4. Successful allocation is not proof of compatible cleanup

The aarch64 SDK declares convenience functions such as CreatePort() and CreateExtIO() through clib/alib_protos.h. In this build, they could bind to amiga.lib, while the existing release paths used incompatible cleanup.

The result was particularly misleading: the daemon could run, but exiting it crashed.

For the aarch64 keyboard resources, 1.0.5 uses matching Exec operations on both sides:

CreateMsgPort()       -> DeleteMsgPort()
CreateIORequest(...)  -> DeleteIORequest(...)

The timer request similarly moves to CreateIORequest() and a corresponding DeleteIORequest() during cleanup. This describes the aarch64 branch; the minimal-runtime branch retains its own wrappers.

The broader lesson is not that one allocator family is universally better. It is that the selected constructor, allocator and destructor must agree in the actual linked binary. Header declarations and compatibility libraries are part of that investigation.

5. A timeout response is not cancellation

The remote-execution limits are as important as the target list.

On the i386 and aarch64 child-task path, a command still running after 30 seconds gets a timeout notice and exit status 124. The command can continue running. A caller must not interpret that status as confirmation that the work has stopped, especially before retrying something that writes data.

A command typed inside the interactive SSH shell is a separate case: it runs inside the daemon and can hold up other connections. This is not a complete Linux-style PTY environment. Remote pipes, redirection and unsupported stdin-driven commands are deliberately rejected rather than treated as supported features.

For automation, start with a short command:

ssh user@AROS_IP Version > aros-version.txt

Here, the PC's shell handles > aros-version.txt. That is different from putting the redirection inside the quoted command sent to AROS.

6. Validate the failure paths and the public package

The versioned aarch64 checklist records:

• Five crypto self-tests and 100 sequential logins.
• SCP/SFTP transfers in both directions, byte comparisons and shorter-file overwrites.
• Twenty zero-delay stress iterations, totalling 80 transfers up to 1 MiB.
• Native console input, including cursor sequences followed by a character in the same packet.
• Shutdown with Break, followed by restarting the daemon.

Those are project-recorded results, not tests rerun for this article. They also have boundaries. High-volume debug logging to a console froze the Pi during stress, while the default logging level passed. QEMU raspi3b with usb-net had very slow reception and a failed upload that did not reproduce on the Pi 400.

The package checks matter too: validating local build output does not prove that the public archive contains those binaries. The release smoke script can download the published archive, check expected hashes and reject unintended hosted artifacts.

Finally, pin claims to the release. The three public AROS 1.0.5 tags point to 188e301. The later e3599e2 fix for logging without a shell channel is on the subsequent development branch, not in those 1.0.5 packages.

What this port does not establish

These fixes do not turn the underlying system into a hardened general-purpose SSH appliance. Full PTY behavior remains incomplete. The porting notes describe entropy-generation limitations and a best-effort fallback rather than an available system CSPRNG in this environment. Remote accessibility and modern cipher support do not remove those constraints.

What the port does illustrate is a useful debugging sequence: trace the input source, verify the API's handle type, match resource lifecycles, distinguish timeout from cancellation, and test the exact package users download.

Sources and disclosure

• BebboSSH AROS repository and upstream attribution.
• Porting notes at the aarch64 1.0.5 tag.
• Related AndroidLab guide: installation, architecture differences and operational limits.

I maintain this fork and write for AndroidLab. The source project is derived from Stefan "Bebbo" Franke's BebboSSH and is licensed under GPLv3 or later; the code excerpts above are adapted from that project. This article was prepared with AI assistance and checked against the versioned source and release documentation. No new hardware test is claimed.