返回首页
最新
prmana 用短期有效的 OIDC 令牌替代了静态 SSH 密钥，这些令牌通过 PAM 在主机上进行验证。与其他 OIDC-for-SSH 方法不同的是，prmana 使用了 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的源代码并指向它，但经过几个小时后情况没有好转。我在这里提问是因为其他地方对AI的关注度远不如这里，但对于这样一个简单的问题，我决定同时尝试构建自己的网络容器……这真是让人头疼。首先，我代理了本地流量，忘记了Codex需要openai.com/chatgpt.com才能工作。然后我遇到了systemd-resolved绑定:53 SO_BINDTODEVICE的问题，这可能是我认为自己知道最好的一种症状，因此我无法重定向DNS。还有很多其他的小问题，但一周后，我认为这是一次非常有趣的Linux网络深度探索。
总之，我在这里的成果[1]虽然是一次性的，但也是构建网络命名空间容器的一个非常有用的指南。希望它能为其他人提供有用的路线图。
1. https://gist.github.com/orbisvicis/347fb8439b658fd6161486f3de1e1ea0