tinyssh: add package

[Oppen]

📦 Package Details

Maintainer: @Oppen

Description:

TinySSH is a minimalistic SSH server which implements only a subset of
SSHv2 features.

Pinned to 3d93382 due to unreleased security fixes.

Ships tinysshd-listen, a small accept-and-fork TCP supervisor to avoid
heavier deps or busybox changes. Skips RELRO to stay small; safe since
it parses no input.

---

🧪 Run Testing Details

• OpenWrt Version: 25.12.4
• OpenWrt Target/Subtarget: mipsel_24kc
• OpenWrt Device: Tp-Link Archer C20 v5

root@OpenWrt:~# apk add --allow-untrusted /tmp/tinyssh-2026.06.13~3d93382c-r1.apk
(1/1) Installing tinyssh (2026.06.13~3d93382c-r1)
  Executing tinyssh-2026.06.13~3d93382c-r1.post-install
OK: 16.2 MiB in 157 packages
root@OpenWrt:~# uci set tinyssh.main.port='2222'
root@OpenWrt:~# uci commit tinyssh
root@OpenWrt:~# /etc/init.d/tinyssh enable
root@OpenWrt:~# /etc/init.d/tinyssh restart
root@OpenWrt:~# netstat -tlnp | grep 2222
tcp        0      0 0.0.0.0:2222            0.0.0.0:*               LISTEN      21049/tinysshd-list
root@OpenWrt:~# wc -c /etc/tinyssh/sshkeydir/*
32 /etc/tinyssh/sshkeydir/ed25519.pk

### NOTE: I'm not sure what's the correct way to handle this, should it read dropbear's directory? In my experience, even dropbear is not finding those keys there, but the web UI places them in that dir
root@OpenWrt:/overlay/upper# mkdir /root/.ssh
root@OpenWrt:/overlay/upper# ln -s /etc/dropbear/authorized_keys /root/.ssh/

pelito@MacBook-Pro-4 ~ % ssh -p 2222 root@192.168.0.2


BusyBox v1.37.0 (2026-06-11 08:43:35 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 25.12.4, r32933-4ccb782af7 Dave's Guitar
 -----------------------------------------------------

 OpenWrt recently switched to the "apk" package manager!

 OPKG Command           APK Equivalent      Description
 ------------------------------------------------------------------
 opkg install <pkg>     apk add <pkg>       Install a package
 opkg remove <pkg>      apk del <pkg>       Remove a package
 opkg upgrade           apk upgrade         Upgrade all packages
 opkg files <pkg>       apk info -L <pkg>   List package contents
 opkg list-installed    apk info            List installed packages
 opkg update            apk update          Update package lists
 opkg search <pkg>      apk search <pkg>    Search for packages
 ------------------------------------------------------------------

For more information visit:
https://openwrt.org/docs/guide-user/additional-software/opkg-to-apk-cheatsheet

root@OpenWrt:~#

---

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[openwrt-ai]

Reviewed the new tinyssh package (1 commit, fresh review). The commit message matches the changes. Two inline notes below: a data race on the live connection counter shared with the SIGCHLD handler, and an IPv6-reachability question in the init script. The RELRO drop for tinysshd-listen and the LDFLAGS filter look correct against include/hardening.mk.

---

Generated by Claude Code

[openwrt-ai]

live is read-modify-written both here (live++) and in the reap() SIGCHLD handler (live--, line 19). sig_atomic_t only guarantees atomicity for a single read or write, not for a read-modify-write, and reap() can interrupt the main thread mid-update. If SIGCHLD is delivered while live++ is in flight (load/add/store), the handler's decrement is overwritten and lost, so live drifts upward over time. Once it is stuck at >= maxconns the supervisor refuses every new connection — a slow self-inflicted DoS whenever -c is used (the init passes -c 20 by default).

Consider blocking SIGCHLD with sigprocmask around the live >= maxconns check and the increment, or reaping synchronously in the accept loop instead of mutating the counter from the handler.

---

Generated by Claude Code

[openwrt-ai]

nit: bindaddr defaults to 0.0.0.0 and, when an interface is configured, only network_get_ipaddr (IPv4) is consulted, so tinysshd-listen is only ever handed an IPv4 address — even though it fully supports AF_INET6. As written IPv6 clients can never reach the daemon, which differs from dropbear (the in-tree SSH server) that listens on both families by default. Is IPv4-only intended, or should the default / interface handling also cover IPv6 (e.g. a second procd instance bound to :: or the interface's IPv6 address via network_get_ipaddr6)?

---

Generated by Claude Code

[BKPepe]

Look, I'm wondering why we should add another package to the SSH category when we already have plenty of packages focused on this. Do you have a comparison with the other SSH packages we have here? I don't really think it's appropriate to keep adding more packages when we already have existing ones, because that would be choosing quantity over quality. Plus, you mention in the pull request yourself that it would be advisable to use the latest versions containing security fixes, and considering this is the first pull request for adding tinyssh... I'm just being cautious, nothing more.

[Oppen]

Look, I'm wondering why we should add another package to the SSH category when we already have plenty of packages focused on this. Do you have a comparison with the other SSH packages we have here?

The main difference in my view here is that its memory overhead when not connected is minimized by only having the socket listener. Then, reduced scope. I tend to prefer my systems (specially my router, which is a rather limited model) to only do what they need to do, and I don't need the client functionality or the scp that dropbear comes with.

I don't know the tmate client (just found about it with apk search ssh), but compared to dropbear it provides better isolation I believe, given there is one process per connection, the binary is ~40kB smaller, compared with OpenSSH it's significantly smaller, has fewer moving pieces, but lacks some security features like privilege separation.The crypto is all libraries by DJB (cr.yp.to subdomains), vendored. It supports only private key login which for me is a plus, can't misconfigure that.

Just to be clear, even though I'd very much like it to be included, I'm gonna use it for myself and if you don't want to merge it it's OK with me, I'm just explaining why I personally prefer this client.

I don't really think it's appropriate to keep adding more packages when we already have existing ones, because that would be choosing quantity over quality.

I understand. I didn't know we had more than dropbear honestly. I know what they say about "assume", but I assumed that really, didn't expect many others and didn't find the one I wanted to use :)

Plus, you mention in the pull request yourself that it would be advisable to use the latest versions containing security fixes, and considering this is the first pull request for adding tinyssh...

Isn't this true for any security-relevant package? The release cadence seems to be about bi-monthly and there are ~12 commits after the latest release starting June.
I think I mischaracterized the commits, the only one that seems security relevant is this potential OOB read, but now I'm not so sure. I don't think it would be bad to revert to 20260601 release.

I'm just being cautious, nothing more.

That's a healthy attitude, yes.

EDIT: not I see the CI failures and AI review, but I think since this might be blocking I'm gonna wait until we resolve whether this has a chance of merging in the first place before trying to address them.