From 50c12d9e16d043de3ce0f7d859cf9ac8d954870b Mon Sep 17 00:00:00 2001 From: anti Date: Sat, 25 Apr 2026 04:53:04 -0400 Subject: [PATCH] docs(debt): DEBT-038 #5 closed by telnet extension f1026b4 --- development/DEBT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/development/DEBT.md b/development/DEBT.md index 7f5cab8b..e2f5144e 100644 --- a/development/DEBT.md +++ b/development/DEBT.md @@ -380,7 +380,7 @@ The SSH cred-capture path that closes the "real OpenSSH doesn't log attempted pa 4. **Pubkey attempts not captured.** Pubkey auth runs through a separate PAM path; password-only is v1 by intent. Capturing pubkey attempt fingerprints (key-type, comment, fingerprint hash) needs a parallel hook into sshd's pubkey path, not pam_exec. Valuable signal but lower reuse density than passwords — defer until v2 or until cred-reuse analytics surface a need. -5. **Telnet has the same gap.** `templates/telnet/` uses `/bin/login` PAM, which (like real OpenSSH) does not log attempted passwords. The `auth-helper` binary is generic — same line in `/etc/pam.d/login` extends capture to telnet at the cost of one Dockerfile change. Tracked here, not as a separate DEBT, so it lands as a follow-up to this one rather than its own ticket. **Verification step required before doing the work**: confirm telnet currently *doesn't* capture passwords — earlier conversation conflated the auth syslog lines (which carry user but not password) with cred capture. +5. **Telnet had the same gap — closed in commit `f1026b4`.** Telnet's busybox-telnetd → `/bin/login` PAM stack didn't log attempted passwords either; the `auth-helper` binary is service-agnostic and was extended into `/etc/pam.d/login` via the same one-line PAM hook. The canonical source moved to `decnet/templates/_shared/auth-helper/auth-helper.c` and is synced into both ssh/ and telnet/ build contexts via `_sync_auth_helper_sources()` (mirrors the existing sessrec sync). Limitations 1–4 above apply equally to the telnet hook. **Status:** Open — document-only ticket tracking the architectural trade-offs of the v1 implementation. None of these are blocking; they're the things to know if the helper ever needs upgrading.