在GitHub中生成个人访问令牌后,是否有必要将其存储在机器本地的某个地方?

如果是,是否有首选的存储方式?


当前回答

在我的用例中,我将PAT存储在密码管理器中,例如LastPass, KeePass, 1Password。当我在Linux环境(例如Docker)中需要它时,我将PAT保存在一个环境变量中,然后使用git的凭据帮助器设置。例如:

git config --global credential.helper 'cache --timeout 600'

<< eof tr -d ' ' | git credential-cache store 
  protocol=https
  host=github.com
  username=nonce
  password=${GITHUB_PAT}
eof

对于PAT,用户名可以是任何东西,除了空白。以下是详细阐述的要点:

https://gist.github.com/rwcitek/da862e9e27cc28d3e96e62a2ca4b2b64

其他回答

基本上我是在我的机器上做的:

https://gist.github.com/bsara/5c4d90db3016814a3d2fe38d314f9c23

我的配置文件脚本与描述略有不同:

env=~/.ssh/agent.env

agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; }

agent_start () {
    (umask 077; ssh-agent >| "$env")
        . "$env" >| /dev/null ; 
}

agent_load_env

# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running
agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?)

if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then
    agent_start
    ssh-add
elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then
    ssh-add
fi

unset env

安装Git凭证管理器!https://github.com/GitCredentialManager/git-credential-manager。GCM支持缓存以及在会话之间持久存在的各种特定于平台的凭据存储。

更棒的是:GCM支持用户友好的安全认证GitHub和GitLab通过web浏览器与OAuth。这意味着您甚至不再需要创建个人访问令牌。当你推送git时,只需按照链接到GitHub并授权应用程序。后续的身份验证不需要交互。

OAuth比个人访问令牌更安全,因为令牌的有效期很短,在需要时使用更长的刷新令牌进行刷新。

以我为例,在Ubuntu中,被接受的解决方案不能处理像这样的消息

Git: 'credential-manager'不是Git命令

但是店长却做得很好:

git config --global credential.helper store

尝试启用此功能以帮助跨推/拉持久化

git config credential.helper store

对于正在克隆的repo / macOS用户/安装iTerm2 https://iterm2.com/

使直到

只要在需要时单击该片段即可。 另外,你在用哦,我的zsh,对吧? https://github.com/ohmyzsh/ohmyzsh

好吧,你必须把令牌保存在某个地方,当你不想每次你的应用程序要求输入它时:-)

一个很好的解决方案是使用环境变量,正如在一个评论中已经建议的那样。

但你仍然需要在某处设置环境变量。 在Windows(我正在使用)上,你可以使用系统设置中的对话框(我不知道其他操作系统是否有类似的东西)。

我不这么做,我更喜欢在我的项目中使用脚本。 在私有项目中,您可以将此提交给源代码控制,但这是一个偏好问题。

在我的一个个人项目中,我也使用个人访问令牌调用GitHub API。 这是一个命令行应用程序,最终用户将在配置文件中保存令牌(这是OK的)。

但我也需要开发令牌,因为项目有集成测试,我正在调用GitHub API。

这个项目在GitHub上是公开的,所以我无法在源代码控制中保存令牌。

我所做的是:

我有一个批处理文件(记住,我在Windows上),名为environment-variables.bat,它设置所有必需的环境变量,包括访问令牌 我在构建脚本和用于运行测试的批处理文件中调用此函数 在源代码控制中会忽略Environment-variables.bat 但是在源代码控制中,有environment-variables.bat。相反,其中包含相同的,但假的令牌/密码。

因此,我只需将该文件重命名为environment-variables.bat,将假密码替换为真实密码,就可以正常工作了。


不过,这并不是所有情况下的完美解决方案。

在我的项目中,我有一个问题,我需要在未来为更多的api使用更多的令牌/密码。

因此,我的environment-variables.bat中的令牌数量将会增加,这使得潜在的参与者很难实际执行所有集成测试。我到现在都不知道该怎么办。