Gentoo 仓库里搜 ssh-askpass，能翻出五个包。但只要关掉全局 X11（打开 -X USE flag），这五个包没一个真正省心——要么直接报错要装 X11，要么编译到一半才发现骨子里也没脱开。一位用 hardened Gentoo 加 Sway 桌面的用户最近撞上这堵墙，干脆自己用 Zig 0.16 和 GTK4 写了一个纯 Wayland 版本，连 GTK 绑定都是手写的。
这不是闲得没事干。真实场景是：go get 这类工具在没有终端（TTY）的自动化构建里，要通过 SSH 用 ED25519 私钥拉私有 Git 模块。没有终端可以直接输密码，OpenSSH 只能调用 SSH_ASKPASS 弹一个窗口要口令。这个窗口用什么画，在纯 Wayland 机器上就成了绕不开的麻烦。
五个官方候选，没一个真正省心
| 包名 | 是否需要 X11 | 额外依赖 | 问题 |
|---|---|---|---|
| ksshaskpass | 不需要 | ~20 个 KDE Frameworks + KWallet、qtkeychain | 能装，但为装个密码框搬来大半套 KDE |
| lxqt-openssh-askpass | 需要 | Qt | 直接卡在 X11 这一步 |
| ssh-askpass-fullscreen | 需要 | GTK2 + X11 版 Cairo | 同上，还带老式 GTK2 |
| x11-ssh-askpass | 需要 | imake 构建系统 | 名字里就写着 X11 |
| gnome-ssh-askpass | 表面不需要 | 源码含 gdk/gdkx.h | ebuild 没声明 X11，编译时才炸 |
五个里，真正能在纯 Wayland 机器上编译通过的只有 ksshaskpass。但它把一个原本几十行代码就能干完的活，变成了装大半套 KDE。对一个只想留住 Sway + GTK 极简桌面的人，这笔账不划算。
gnome-ssh-askpass 的暗坑，才是真正的导火索
gnome-ssh-askpass 看着最有希望。ebuild 没写要 X11，理论上应该能装。
一编译就炸：源码里一行 #include <gdk/gdkx.h>，这个头文件只在 X11 版 GDK 里存在。纯 Wayland 环境根本没有它，构建直接中断。
包管理器声明的依赖是一回事，源码里的真实依赖是另一回事。这类"忘了删的老代码"在维护多年的开源工具里并不罕见，不只这一个项目会踩。
顺带一提背景：OpenSSH 从 8.4 版本起，用 SSH_ASKPASS_REQUIRE 环境变量控制何时弹窗（force/prefer/never），没有可用终端时才会真正调用 SSH_ASKPASS。这也是为什么问题只出现在无 TTY 的自动化构建里，日常交互式 SSH 登录基本碰不到。
谁真的用得上，谁不用管
真正会关心这件事的，是两类人：刻意维持精简依赖的 Gentoo、Sway 用户；以及在无 TTY 的 CI 或自动化构建里，要用 SSH 拉私有仓库的开发者，比如走私有 Git 的 Go 模块。
普通用 GNOME、KDE 或装了完整 X11 兼容层的 Linux 用户，五个包基本都能正常装，不会遇到这种连环失败。
对多数人，现在还不用急着抄这个方案。作者公开的只是问题和技术选型——Zig 0.16、GTK4、手写绑定——没有仓库地址、依赖体积或安全审计，能不能真正替代 ksshaskpass 还不确定。
要在无 TTY 环境处理私有仓库密钥，更稳妥的临时办法是用 SSH agent 转发或部署密钥，避免每次构建都靠一个弹窗输入私钥口令。
值得盯的是这个工具会不会走出个人仓库，进 Gentoo 官方树，或者被其他纯 Wayland 用户复用——目前看不到。