#265 SSH hangs at "Opening Channel" when SFTP subsystem opens but FXP_INIT never completes

[DaiTengu]

Summary

---

With "SFTP Public Key" enabled for a dialing-directory entry, SyncTERM hangs
forever at the "Opening Channel" popup when connecting via SSH to a server
that accepts the sftp subsystem channel but never returns a usable
SSH_FXP_INIT reply (e.g. a BBS whose SSH server has no working SFTP behind it).

Repro

---

1. Enable "SFTP Public Key" for an entry whose host accepts the sftp
   subsystem channel-open but doesn't actually serve SFTP.
2. Connect via SSH. Auth succeeds, then it sticks at "Opening Channel"
   indefinitely (never times out).

Root cause

---

In sftp_session_start() the FXP_INIT round-trip waits with
WaitForEvent(init_evt, INFINITE); // src/syncterm/ssh.c:844
That event is only ever signalled by sftp_init_signal_cb (on a valid FXP_INIT
reply). If the reply never arrives, the recv thread hits EOF/error and breaks
(ssh.c:750-753) without signalling the event, so the wait never returns.

The wait is a hand-rolled Win32 event, so it is NOT covered by the 60s
dssh_session_set_timeout (ssh.c:1094) that guards the DeuceSSH-level waits
(e.g. send_channel_request_wait, ssh-conn.c:1883). "Opening Channel" is also
still displayed because the popup isn't cleared until after this call
(ssh.c:1238).

Version

---

SyncTERM 1.10a, built from the Synchronet git tree (MSVC + vendored Botan),
Windows 11.

[DaiTengu]

bah, I refreshed the page and it reset the version/milestone.

[Stephen James Hurd]

I've made it abortable now, but this should maybe do the SFTP update in the background rather than block the shell until it completes, leaving it open pending a decision on that.