https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517
--- Comment #7 from Martin Renvoize (ashimema) <[email protected]> --- I think that suggestion points at the right destination, but the wrong bug to do it in. Agreed on the direction: an explicit trust ceremony (do the handshake, show the fingerprint, staff confirm, Koha remembers the key) is the standard UX in every serious SFTP client and is genuinely stronger than accept-new. Trust-on-first-use is only as strong as your first connection not being intercepted, whereas a displayed fingerprint can be checked out-of-band against what the vendor published. It also degrades gracefully on key rotation: the connection fails and staff re-confirm the new fingerprint through the same flow. The strongest argument for it, though, is where the trust gets stored rather than the modal itself. Today trust lives in ~koha/.ssh/known_hosts, which is filesystem-local state: - Multiple app servers each have their own known_hosts, so accept-new has to happen once per box, and 'yes' fails on any box that hasn't connected yet. - Ephemeral deployments (containers) lose the file on redeploy, so 'yes' breaks after every rebuild. - It's shared with everything else the koha user does over SSH, and with every other transport; there is no per-transport trust. A confirm-and-pin flow would naturally store the accepted host key on the file_transports row, and the implementation is clean with Net::SFTP::Foreign: write the pinned key to a temporary file at connect time and pass -o UserKnownHostsFile=... -o StrictHostKeyChecking=yes. Trust becomes deployment-independent, per-transport and auditable. Why I don't think it should block this bug: 1. Scope. This bug is a small self-service knob: stop hardcoding StrictHostKeyChecking=no. The proposal is a feature: a keyscan step (probably a synchronous API endpoint, since the existing connection test runs as a background job), fingerprint UI handling multiple key types, DB storage of pinned keys, and a re-confirm flow on key change. That deserves its own bug. 2. They're not mutually exclusive. The enum survives either way: 'no' stays useful for dev/test, and a pinning feature is essentially how 'yes' becomes actually usable in production. Nothing in this patchset paints us into a corner; the pinning work slots in behind the same column. 3. An honest limitation of the modal too: ssh-keyscan is subject to the same first-connection interception risk as accept-new. The modal only adds security if staff actually compare the fingerprint against an out-of-band value. It makes informed trust possible, which is worth doing, but the marginal security of blocking this bug on it is small, while the operational value of accept-new over the hardcoded 'no' is immediate. So my proposal: land this bug as the incremental improvement it is, and open a follow-up bug for "confirm and pin host keys per file transport" (fingerprint confirmation UI, key stored on the transport row, connections made with a generated UserKnownHostsFile and strict checking). The multi-server/ephemeral-deployment argument should go in that follow-up, because that is where the current known_hosts approach actually breaks. A cheap middle step in the meantime: the SFTP code already captures the ssh -v stderr, so after an accept-new first connection the accepted fingerprint is in the debug output. Surfacing it in the transport's status messages would let staff review what was trusted after the fact, without any new handshake machinery. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected] website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
