Git LFS 是否对 Git 客户端使用不同的身份验证逻辑？
Does Git LFS use different authentication logic to Git client?
我们使用本地 Azure DevOps，并且刚刚开始试用 Git LFS。我已经安装了最新的客户端 (3.0.2) 和我的 git（2.31.1.windows.1 由 Visual Studio IIRC 安装）并且在克隆 Git 来自具有 LFS 文件的 DevOps 的 repo。
但是我的本地存储库只引用了 LFS 文件，当尝试 运行 命令如 git lfs pull（或获取，或推送新的 LFS 跟踪文件）时，我收到与以下相关的身份验证错误http://<server>:8080/tfs/<collection>/<project>/_git/<repo>.git/info/lfs - 即我们的 git 回购 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 都支持，并且是安全的。目前，如果您将 NTLM 设置为使用 Negotiate，Git LFS 将无法正常工作，因为它优先于 Negotiate 而不是 Basic。在即将到来的 3.1 中，预计本月或下个月，如果 Negotiate 失败，Git LFS 将回退到 Basic，因此即使您启用了 NTLM 也可以工作你的实例。
我强烈建议大家摆脱 NTLM，因为它非常不安全。真的没有理由再使用它了：甚至 Microsoft 都会告诉您将其关闭。如果您在您的实例上关闭 NTLM，或切换到 Kerberos，一切应该都能正常工作。否则，您需要等待 Git LFS 3.1 或在配置中将身份验证方法显式设置为 basic。
我们使用本地 Azure DevOps，并且刚刚开始试用 Git LFS。我已经安装了最新的客户端 (3.0.2) 和我的 git（2.31.1.windows.1 由 Visual Studio IIRC 安装）并且在克隆 Git 来自具有 LFS 文件的 DevOps 的 repo。
但是我的本地存储库只引用了 LFS 文件，当尝试 运行 命令如 git lfs pull（或获取，或推送新的 LFS 跟踪文件）时，我收到与以下相关的身份验证错误http://<server>:8080/tfs/<collection>/<project>/_git/<repo>.git/info/lfs - 即我们的 git 回购 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 都支持，并且是安全的。目前，如果您将 NTLM 设置为使用 Negotiate，Git LFS 将无法正常工作，因为它优先于 Negotiate 而不是 Basic。在即将到来的 3.1 中，预计本月或下个月，如果 Negotiate 失败，Git LFS 将回退到 Basic，因此即使您启用了 NTLM 也可以工作你的实例。
我强烈建议大家摆脱 NTLM，因为它非常不安全。真的没有理由再使用它了：甚至 Microsoft 都会告诉您将其关闭。如果您在您的实例上关闭 NTLM，或切换到 Kerberos，一切应该都能正常工作。否则，您需要等待 Git LFS 3.1 或在配置中将身份验证方法显式设置为 basic。