Mr.*_*Boy 3 git git-lfs azure-devops
我们使用本地 Azure DevOps，并且刚刚开始试用 Git LFS。我已经安装了最新的客户端 (3.0.2) 和 git（由 Visual Studio IIRC 安装的 2.31.1.windows.1），当从具有 LFS 文件的 DevOps 克隆 Git 存储库时，一切最初看起来都很好。
然而，我的本地存储库仅引用了 LFS 文件，当尝试运行git lfs pull（或获取或推送新的 LFS 跟踪文件）等命令时，我收到与http://<server>:8080/tfs/<collection>/<project>/_git/<repo>.git/info/lfsgit 存储库 URL 的子路径相关的身份验证错误。
谷歌搜索已经向其他人展示了类似的问题，但没有明确回答发生了什么，或者为什么，或者如何解决它。我不明白这是 DevOps 实施问题还是我这边的本地客户端问题。
我确实遇到过关于 Git LFS 不使用与 Git 相同的凭据或身份验证类型的讨论，或者可能在不同的位置寻找它们 - 请注意，我们在本地使用 HTTP 而不是 HTTPS，也许这是一个因素？
Git LFS 使用与 Git 中不同的 HTTP 和 TLS 库。Git 使用 libcurl，Git LFS 使用 Go HTTP 库。因此，尽管两个程序都将使用 Git 凭证帮助程序和其他凭证查找逻辑，但支持的身份验证逻辑不同。
既然您提到了 Azure DevOps，我猜测您正在使用 NTLM。在 3.0 中，Git LFS 删除了 NTLM，因为它有已知的错误，但没有人有兴趣修复它们，而且它使用自 1995 年以来已知不安全的加密技术。Azure DevOps 是唯一已知使用 NTLM 的主要站点，Git LFS 维护者询问如果他们愿意参与帮助维护它，但他们拒绝了。
NTLM 可以通过以下两种方式之一进行处理：通过NTLM身份验证方案或Negotiate方案。Kerberos 也使用后者，Git 和 Git LFS 都支持 Kerberos，而且它是安全的。目前，如果您设置了 NTLM 以使用Negotiate，Git LFS 根本无法工作，因为它优先Negotiate于Basic. 在即将推出的 3.1 中，预计本月或下个月发布，Git LFS 将在失败Basic时回退Negotiate，因此即使您在实例上启用了 NTLM，您也可以工作。
我强烈鼓励大家摆脱 NTLM，因为它非常不安全。确实没有再使用它的正当理由：甚至微软也告诉你将其关闭。如果您在实例上关闭 NTLM，或切换到 Kerberos，一切都应该正常。否则，您需要等待 Git LFS 3.1 或basic在配置中显式设置身份验证方法。