WindTerm 连接内网 OpenSSH_7.4 服务器时，在认证弹窗出现前超时

环境：
- WindTerm 版本：2.7.0 Windows Portable x86_64
- 也测试过：2.6.1 Windows Portable x86_64，结果相同
- 操作系统：Windows 11
- 服务端：Linux，OpenSSH_7.4
- 目标地址：10.1.101.52:22
- 代理：无
- 认证方式：密码认证

问题描述：
WindTerm 无法连接多台内网 SSH 服务器。连接时不会弹出用户名/密码输入窗口，而是等待一段时间后提示：
Time out, please try again

但是同一台 Windows 电脑上，使用系统自带 OpenSSH 可以正常连接：
ssh 用户名@10.1.101.52

WindTerm 连接云服务器是正常的，会弹出认证窗口。因此问题似乎只出现在这批内网 OpenSSH_7.4 服务器上。

已经尝试过的操作：
新建全新的 WindTerm profile
新建最简单的 SSH 会话，只配置主机 10.1.101.52 和端口 22
确认未配置代理
关闭 SFTP
关闭 Sysmon
关闭服务器指纹验证
关闭公钥认证、键盘交互认证、GSSAPI，只保留密码认证
分别测试 WindTerm 2.7.0 和 2.6.1，结果相同

网络层观察：
使用 Windows 的 Get-NetTCPConnection 观察到，WindTerm 实际上已经和 10.1.101.52:22 建立了 TCP 连接，状态为 Established。
但大约 20 秒后，WindTerm 主动断开连接，并提示 timeout。
这说明网络、端口、防火墙和代理应该不是主要问题，更像是 SSH 握手或认证前阶段发生了兼容性问题。
Windows OpenSSH 调试信息：
Windows 自带 OpenSSH 可以到达 SSH 协商阶段，服务端 banner 如下：
Remote protocol version 2.0, remote software version OpenSSH_7.4

期望行为：
WindTerm 应继续完成 SSH 握手，并弹出用户名/密码认证窗口。

实际行为：
WindTerm 在认证窗口出现前超时，无法登录。

补充说明：
同一台电脑、同一网络环境下，Windows OpenSSH 可以连接成功；WindTerm 连接其他云服务器也正常。问题主要出现在这些内网 OpenSSH_7.4 服务器上。
请问是否可以开启更详细的 WindTerm SSH/libssh 调试日志，以便进一步定位问题？

可能相关的历史问题：
- #612：内网 SSH 服务器 WindTerm timeout，但 MobaXterm 可以连接
- #1012：连接 OpenSSH_7.4 服务器时无响应/异常
- #1685：连接部分 OpenSSH 版本设备异常
- #646：关闭 SFTP 后仍无法连接，但 CRT/PuTTY 可以

补充：我看到 #612 的现象和我这里非常类似：都是内网 SSH 服务器 WindTerm timeout，但其他 SSH 客户端可以正常连接；关闭 SFTP 后仍然无法解决。因此我怀疑这是同一类 SSH/libssh 兼容性问题。

开启 `Log all session output` 后，WindTerm 日志显示 TCP socket 已经连接成功：
[10.1.101.52_2026-06-25_17-55-01.log](https://github.com/user-attachments/files/29332058/10.1.101.52_2026-06-25_17-55-01.log)
socket_callback_connected: Socket connection callback: 1 (0)
但之后一直停留在：ssh_connect: current state : 2
持续约 20 秒，期间没有出现：
callback_receive_banner
SSH server banner
SSH-2.0-OpenSSH_7.4
SSH_MSG_KEXINIT
最后 WindTerm/libssh 发送 disconnect 包：
packet_send2: packet: wrote [type=1 ...]
因此问题发生在 SSH banner / identification 阶段，尚未进入 host key、KEX、认证、SFTP 阶段

No repository file or test is named. Reproduce the connection to an OpenSSH_7.4 server and inspect the SSH state around ssh_connect, callback_receive_banner, and the logged packet_send2 disconnect; done means the banner is received, the handshake continues, and the authentication prompt appears.

Written by the indexing model from the issue text.