logo标签列表

Git推送 - 在远程URL中包含用户名和密码

gitgithubpush
11

据我了解，在推送到github时可以通过在远程推送网址中添加用户名:密码来避免输入密码提示。

https://you:password@github.com/you/example.git

这是 GitHub 特有的安排吗？还是说这种格式 (https://username:password@somedomain.org/repo.git) 可以用于任何 Git 远程仓库？

5
user:password@host这种格式并不是git特有的，它是基本HTTP认证。我认为在使用ssh://协议的git远程仓库时无法使用此格式。 - Cristian Lupascu
谢谢@w0lf！有没有自动推送到远程仓库的方法？ - chamilad
1
“git push”是一个可以在命令行或脚本中输入的命令。因此，您可以以任何您喜欢的方式自动化它。 - Cristian Lupascu
我的意思是是否有一种自动推送的方法，而不需要提示输入用户名和密码？假设用户名和密码在代码中已经可用？ - chamilad
我不确定你是否能够这样做。如果可能的话，你可以尝试使用SSH密钥。 - Cristian Lupascu
好的。谢谢@wolf！你能把第一条评论加为答案吗，这样我就可以接受它了？ :) - chamilad
5个回答
7
通过 GitHub 进行身份验证的更安全的方法，而不是将密码放入远程 URL 中，是如果您使用 HTTPS，在 此 GitHub 页面生成一个新的令牌，然后像这样构建您的远程 URL：
https://<username>:<token>@github.com/<username>/<project_name>.git
4

这是Github特定的安排吗？

这不是Github特定的；实际上这是基本的HTTP身份验证。使用user:password@host技巧是一种在URL中指定BA凭据的方式。

...这种格式可以与任何git远程一起使用吗（https://username:password@somedomain.org/repo.git）？

它仅适用于使用HTTP协议的远程。对于SSH远程，您必须使用SSH密钥。

3
Git push自 Git 2.9.3（2016年8月）以来就不再显示密码，但是为了保险起见，提交 c1284b2（由 Johannes Schindelin（dscho）于2019年3月4日提交）改进了remote-http传输，使其在错误消息中匿名化URL。合并后由Junio C Hamano -- gitster于2019年4月16日提交的提交764bd20。

curl：在错误消息和警告中匿名化URL

它在用户面向的错误消息和警告中匿名化URL（即删除用户名称，特别是密码）。

在 Git 2.27（2020年第二季度）之前，“git push”中的错误和详细跟踪消息没有隐藏嵌入在URL中的凭据信息。

请参见提交d192fa5（由 Johannes Schindelin (dscho)于2020年4月24日提交）。 （由Junio C Hamano -- gitster --合并于提交2c42fb7，2020年5月1日）

push：在错误信息和警告中匿名化URL

签署者：Johannes Schindelin
审核者：Taylor Blau

就像47abd85ba0（"fetch: 在存储之前从URL中删除用户名"，2009-04-17，Git v1.6.4-rc0 -- 合并），以及更晚的882d49ca5c（"push: 在状态输出中匿名化URL"，2016-07-13，Git v2.10.0-rc0 -- 合并列在批处理#7中），甚至更晚的c1284b21f243（"curl: 在错误信息和警告中匿名化URL"，2019-03-04，Git v2.22.0-rc0 -- 合并列在批处理#5中），此更改会在用户面向的错误信息和警告中匿名化URL（即删除它们的用户名和密码）。

1
你可以让本地Git记住GitHub凭据：
如果您使用HTTPS克隆GitHub存储库，您可以使用凭据助手告诉Git每次与GitHub通信时记住您的GitHub用户名和密码。
请查看这篇GitHub文章。
0

清楚地说，像https://you:password@github.com/you/example.git这样在远程URL中使用凭据并不是最佳实践，用户应该被提醒。

Git 2.37（2022年第三季度）提供了这样的警告：transfer.credentialsInUrlfetch.credentialsInUrl配置变量控制在使用嵌入登录凭据的URL时会发生什么。

最初它被称为fetch.credentialsInUrl：

查看 提交 6dcbdc0（2022年6月6日）由Derrick Stolee (derrickstolee)提交。
（由Junio C Hamano -- gitster --合并于提交 11698e5，2022年6月13日）

remote：创建fetch.credentialsInUrl配置

协助者：Junio C Hamano
签署者：Derrick Stolee

用户有时会在明文URL中提供“username:password”组合。
由于Git将这些URL存储为明文，因此这是一种非常不安全的存储凭据的方式。
凭证管理器是一种更安全的存储此信息的方式。

系统管理员可能希望阻止用户在其计算机上使用此类功能。

创建一个新的“fetch.credentialsInUrl”配置选项，并教Git在看到具有此类信息的URL时发出警告或停止执行。
警告将匿名化URL的敏感信息以清楚地说明问题。

（重命名为transfer.credentialsInUrl）

这项更改目前将行为默认设置为“allow”，对这些URL不做任何操作。
如果需要，我们可以考虑将此行为默认更改为“warn”提示。
届时，我们可能希望向仍想遵循此模式（并且不想收到警告）的用户添加有关设置fetch.credentialsInUrl=ignore的建议。

此更改的早期版本将逻辑注入了urlmatch.c中的url_normalize()内。
尽管大多数解析URL的代码路径最终会规范化URL，但该规范化不足以在堆栈早期发生，无法避免首先尝试连接到URL。
通过在远程验证中插入检查，我们在进行连接之前就能识别出问题。

但是，我们可以重用url_normalize()中的解析信息，以从其经过深思熟虑的解析逻辑中受益。
我们可以使用在该方法中创建的结构体url_info来在错误消息中替换密码为“<redacted>”。
这带来了一个小的缺点，即标准化后的URL可能与输入URL略有不同（例如，标准化版本添加了一个结尾斜杠）。
这不应妨碍用户弄清问题并能够解决问题。

为了确保解析逻辑不会捕获任何意外情况，我在本地修改了此更改，将默认设置为“die”选项。
运行测试套件成功，除了t5550-http-fetch-dumb.sh和t5541-http-push-smart.sh中使用的明确用户名:密码URL外。
这意味着所有其他经过测试的URL都没有触发此逻辑。

测试显示出现了正确的错误消息（或者没有出现），还计算了错误消息的数量。
当只有警告时，每个进程都会验证远程URL并输出警告。
克隆时会发生两次，提取时会发生三次，推送时会发生一次。

警告或错误将是：

URL '%s' uses plaintext credentials
在 Git 2.37 (Q3 2022) 中，将 fetch.credentialsInUrl 重命名为 transfer.credentialsInUrl，因为单个配置变量应该在推送和获取中都起作用。

查看 提交 7281c19，提交 4a169da（2022年6月15日），由Ævar Arnfjörð Bjarmason（avar）完成。
（由Junio C Hamano -- gitster --合并于提交 7f5a382，2022年6月17日）

传输文档：将fetch.credentialsInUrl移到"transfer"配置命名空间中

签名者：Ævar Arnfjörð Bjarmason
认可者：Derrick Stolee

将在 6dcbdc0 (Git v2.37.0-rc0 -- merge) 中引入的“fetch.credentialsInUrl”配置变量重命名为“transfer”。 存在某些异常情况，但一般而言，“.”配置仅适用于“namespace”中描述的命令（及其子命令，例如，“clone.”或“fetch.”也可以配置“git-remote-https”）。 但是，在“fetch.credentialsInUrl”的情况下，我们有一个配置变量，它配置了所有“clone”、“push”和“fetch”的行为，调整“fetch.*”配置的人不会期望其影响“git push”(man) 的行为，特别是我们已经有了现有的“{transfer,fetch,receive}.fsckObjects”，它配置传输对话框的不同部分。 因此，在发布之前，让我们将此配置变量移动到“transfer”命名空间。 我们可以在其他时间添加“{transfer,fetch,pull}.credentialsInUrl”，但是一旦我们让“fetch”配置“pull”，这样的安排就会变得混乱不清，因为我们至少需要让“fetch”配置“push”（但不能反过来），或更改现有的行为。

git config现在在其手册页面中包含了：

transfer.credentialsInUrl

配置的 URL 可以包含明文凭据，格式为 <protocol>://<user>:<password>@<domain>/<path>。

您可能希望警告或禁止使用此类配置（而是使用 git credential）。 > 这将用于 git clone, git fetch, git push, 以及任何直接使用配置的 URL。

请注意，目前仅限于检测 remote.<name>.url 配置中的凭据，它不会检测 remote.<name>.pushurl 配置中的凭据。

您可能希望启用此功能以防止意外凭据泄露，例如：

  • 您运行 git 的操作系统或系统可能无法提供方式或以其他方式允许您配置存储用户名和/或密码的配置文件的权限。
  • 即使它可以，将这些数据存储在“静止”状态下可能会以其他方式暴露您，例如备份过程可能会将数据复制到另一个系统。
  • git 程序将完整的 URL 作为命令行参数传递给彼此，这意味着凭据将暴露给其他用户，这些用户在允许其他用户查看其他用户的完整进程列表的操作系统或系统上。在 Linux 上，“hidepid”设置在 procfs（5）中记录了这种行为。

如果您不关心此类问题，则可能不需要担心由于将敏感数据存储在 git 的配置文件中而导致凭据泄露。

如果您确实想使用此功能，请将 transfer.credentialsInUrl 设置为以下值之一：

  • allow（默认）：Git 将继续其活动而不发出警告。
  • warn：Git 在解析具有明文凭据的 URL 时将向 stderr 写入警告消息。
  • die：Git 在解析具有明文凭据的 URL 时将向 stderr 写入失败消息。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接