最新

prmana 用临时的 OIDC 令牌取代了静态 SSH 密钥，这些令牌通过 PAM 在主机上进行验证。它与其他 OIDC-for-SSH 方法的区别在于 DPoP (RFC 9449)——每次身份验证都包含一个加密证明，证明令牌持有者拥有私钥。被盗的令牌无法被重放。 它包含三个组件：一个 PAM 模块 (pam_prmana.so)，一个客户端代理 (prmana-agent) 和一个共享的 OIDC/JWKS 库 (prmana-core)。全部使用 Rust 编写。 DPoP 密钥可以是软件、YubiKey (PKCS#11) 或 TPM 2.0。无需网关，无需 SSH CA，无需对 sshd 进行补丁。标准 ssh 客户端，标准 sshd，PAM 位于两者之间。 已针对 Keycloak、Auth0、Google 和 Entra ID 进行了测试。 这个名字源于梵语——pramana (प्रमाण) 意为“证明”。

这有点奇怪，因为它原本打算以“提问”的形式开始，现在却变成了一个混合的“展示/提问”。 提问是：我到底该如何使用 Codex 的代理网络？我希望 Codex 能够访问在其沙盒之外运行的本地服务（不是 MCP 服务器）。默认的 config.toml 文件附带了以下内容： ``` [permissions.network] # enabled = true # proxy_url = "http://127.0.0.1:43128" # admin_url = "http://127.0.0.1:43129" # enable_socks5 = false # socks_url = "http://127.0.0.1:43130" # enable_socks5_udp = false # allow_upstream_proxy = false # dangerously_allow_non_loopback_proxy = false # dangerously_allow_non_loopback_admin = false # dangerously_allow_all_unix_sockets = false # mode = "limited" # limited | full # allowed_domains = ["api.openai.com"] # denied_domains = ["example.com"] # allow_unix_sockets = ["/var/run/docker.sock"] # allow_local_binding = false ``` 我无法让它工作，所以我下载了 Codex 的源代码并让 Codex 指向它，但几个小时后，情况并没有好转。我曾想在这里提问，因为没有其他地方能 1000% 全力以赴地投入到人工智能中，但对于这样一个简单的问题，我决定同时尝试构建自己的网络容器……这真是个麻烦事。首先，我代理了本地流量，忘记了 codex 需要 openai.com/chatgpt.com 才能工作。然后我遇到了 systemd-resolved 绑定 :53 SO_BINDTODEVICE 的问题，这很可能是“自以为是”综合症的症状，所以我无法重定向 DNS。还有很多其他的“小问题”，但一周后，我认为这是一个对 Linux 网络非常有趣的深入研究。 总之，我在这里 [1] 提供的算是一个一次性的东西，但也是一个非常有用的构建网络命名空间容器的指南。希望它能成为其他人的有用路线图。 1. https://gist.github.com/orbisvicis/347fb8439b658fd6161486f3de1e1ea0