https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 Tristin Stagg <tristin.stagg@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tristin.stagg@bywatersoluti | |ons.com --- Comment #1 from Tristin Stagg <tristin.stagg@bywatersolutions.com> --- Yes! When Koha acts as an SFTP client, often times server administrators will need to go on the server and accept host keys before the integration works. I think we are OK with Koha integrations automatically accepting this on our behalf. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 --- Comment #2 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Should we instead have some step in which the handshake is done, and the new key printed in a modal or smth, and the staff accept/confirm it? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 --- Comment #4 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 198536 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198536&action=edit Bug 42517: Allow option to set StrictHostKeyChecking=accept-new for SFTP This version of the patch sets the option at the file transport level for maximum flexibility and self-service ability. 1) Run updatedatabase.pl 2) Restart all the things! 3) Install and start an SSH server, give the kohadev-koha user a password, allow password auth, and clear any cached host key: apt-get update && apt-get install -y openssh-server mkdir -p /run/sshd && /usr/sbin/sshd echo "kohadev-koha:koha" | chpasswd sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication yes/' /etc/ssh/sshd_config pkill -HUP sshd su - kohadev-koha -c 'rm -f ~/.ssh/known_hosts' 4) In the staff client create a new file transport with Transport: SFTP Host: localhost Port: 22 Strict host key checking: No (always accept the host key automatically) Authentication mode: Password-based Username: kohadev-koha Password: koha 5) Wipe known_hosts again, chnage strict host key checking to yes 6) rm -f ~/.ssh/known_hosts 7) Connection test fails with "Host key verification failed"! 8) Set transport to accept-new 9) Connection test passes! 10) Edit the transport again, switch back to "Yes" 11) Connection test still passes -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 --- Comment #6 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- Created attachment 198538 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198538&action=edit Bug 42517: Update schema file [DO NOT PUSH] Patch from commit 13a257d -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |kyle@bywatersolutions.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |39190 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39190 [Bug 39190] Rework new (S)FTP classes to be polymorphic classes -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 --- Comment #7 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- 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.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #198535|0 |1 is obsolete| | Attachment #198536|0 |1 is obsolete| | Attachment #198537|0 |1 is obsolete| | Attachment #198538|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 --- Comment #9 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202094 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202094&action=edit Bug 42517: Allow option to set StrictHostKeyChecking=accept-new for SFTP This version of the patch sets the option at the file transport level for maximum flexibility and self-service ability. 1) Run updatedatabase.pl 2) Restart all the things! 3) Install and start an SSH server, give the kohadev-koha user a password, allow password auth, and clear any cached host key: apt-get update && apt-get install -y openssh-server mkdir -p /run/sshd && /usr/sbin/sshd echo "kohadev-koha:koha" | chpasswd sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication yes/' /etc/ssh/sshd_config pkill -HUP sshd su - kohadev-koha -c 'rm -f ~/.ssh/known_hosts' 4) In the staff client create a new file transport with Transport: SFTP Host: localhost Port: 22 Strict host key checking: No (always accept the host key automatically) Authentication mode: Password-based Username: kohadev-koha Password: koha 5) Wipe known_hosts again, chnage strict host key checking to yes 6) rm -f ~/.ssh/known_hosts 7) Connection test fails with "Host key verification failed"! 8) Set transport to accept-new 9) Connection test passes! 10) Edit the transport again, switch back to "Yes" 11) Connection test still passes Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 --- Comment #11 from Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> --- Created attachment 202096 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202096&action=edit Bug 42517: Update schema file [DO NOT PUSH] Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42517 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|martin.renvoize@openfifth.c |dcook@prosentient.com.au |o.uk | -- You are receiving this mail because: You are watching all bug changes.