时间戳

首页 > 解决方案 > 安全地将凭据传递给 conda 以访问公司代理通道

conda - 安全地将凭据传递给 conda 以访问公司代理通道

问题描述

不确定这实际上属于 SO，如果有的话，请指出一个更合适的社区...

我正在尝试conda通过 Nexus OSS 托管的公司代理从 Windows 10 工作站访问存储库。连接工作正常，但需要用户将其凭据存储在.condarc文件中：

channels
 - https://<user>:<password>@<my_corp_proxy>/<repo1>/
 - https://<user>:<password>@<my_corp_proxy>/<repo2>/

密码不仅未加密存储在文件中：每当出现错误时都会提示用户，并且以一种更棘手的方式，它还存储在环境目录.json中报告包下载的文件中。conda-meta这是 中的一个已知问题。conda

我对必须将我的密码公开存储感到非常不舒服，尤其是当我们使用 LDAP 身份验证时。我正在寻找一种方法来要求 conda 以更安全的方式检索凭据，但是直到现在，在我在互联网上进行的大量研究中，我都没有找到任何方法。

我试图将我的凭据存储在Windows Credential Manager的Generic Credentials部分中。git:https://<corporate-gitlab-server>似乎适用于 git（由 git 在第一次连接时添加），所以我为 conda 尝试了以下操作：

conda:https://<corporate-nexus-repo>
miniconda3:https://<corporate-nexus-repo>
python:https://<corporate-nexus-repo>

上述配置似乎都不被conda. 所以我们在这里：

标签： condanexuscredentialsminiconda

解决方案

Windows GCM (Git-Credential-Manager-for-Windows) 允许缓存 Git 用于访问远程存储库的凭据：这不适用于其他类型的远程服务（如公司代理）。

在工作中，我们总是使用本地代理（使用当前会话的凭据重定向到实际的公司代理）：genotrance/px（有一个px.exe为 Windows 预编译的）

Px 是一个 HTTP(s) 代理服务器，它允许应用程序通过 NTLM 或 Kerberos 代理服务器进行身份验证，通常用于企业部署，而无需处理实际的握手。

它主要设计用于在 Windows 系统上运行，并使用当前登录的 Windows 用户帐户代表应用程序进行身份验证。

这样，就不会在本地存储任何凭据。

OP Romain Reboulleau在评论中选择了另一种方法：

平台管理团队消除了从 repo 下载进行身份验证的需要。
因此，现在只有使用另一个客户端的存储库管理员才需要凭据，而这个不需要存储凭据。

推荐阅读