本文发表于 446 天前,其中的信息可能已经事过境迁
文章摘要
|

在电视剧《繁花》里有这样一个情节,汪小姐和宝总在一起时喜欢吃排骨年糕,后来两人分道扬镳,汪小姐用 “从此想,排骨是排骨,年糕是年糕” 这句对白来概括两个人的关系。不得不说,这句伤感中带着点文艺的台词,在受到剧粉及书迷追捧的同时,更是戳中了无数吃货的心。排骨年糕好不好吃,我不晓得。我唯一知道的事情是,人们需要亲密关系,可人们同样需要界限和距离感,排骨和年糕,就像是工作和生活,当我们意识到 “工作是工作,生活是生活” 的时候,或许我们就能达到真正的 “Work-Life Balance”。那么,对于程序员来说,工作和生活的界限在哪里呢?我想,这一切或许可以从为 Git 配置多个 SSH Key 说起。

相信大家都会遇到这种场景,即一台电脑上同时存在多个 Git 账号的情况。譬如,公司的项目使用 Gitlab 托管,而个人的项目使用 Github 托管,更不必说,云效、Gitee、码云、Coding 等形形色色的平台。在这种情况下,你需要为每个代码托管平台生成 SSH Key,然后将其对应的公钥复制到指定的位置。所以,如何让这些不同托管平台的 SSH Key 和平共处、互不影响呢?这就是今天这篇文章想要分享的冷知识。当然,对博主个人而言,最主要的目的,还是希望能将公司和个人两个身份区分开来,所以,下面以 Github 和 Gitlab 为例来展示具体的配置过程。

生成 SSH Key

首先,为两个平台生成各自的 SSH Key,使用 ssh-keygen 命令即可:

Bash2 行
12
ssh-keygen -t rsa -C "<公司邮箱>" -f ~/.ssh/company-ssh
ssh-keygen -t rsa -C "<个人邮箱>" -f ~/.ssh/personal-ssh

考虑到安全性问题,现在更推荐使用 Ed2519 加密算法,此时,你只需要替换上述命令中的 rsa 为 ed2519 即可。

配置 Config

接下来,我们需要为本地的 SSH 配置上个步骤中生成的两个 SSH Key。通常,这个配置文件存在于以下路径:

  • Linux: ~/.ssh/config
  • Windows: C:\Users\<Your-User>\.ssh\config

如果在 Windows 系统下找不到该文件,我们直接创建一个无扩展名的文本文件即可:

conf8 行
12345678
Host gitlab.com
    HostName gitlab.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/company-ssh
Host github.com
    HostName ssh.github.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/personal-ssh

其中,Host 这一行表示该配置项的唯一标识,HostName 表示需要连接的目标服务器,IdentityFile 表示私钥文件的路径。可以注意到,我们这里共有两个 SSH Key 的配置,它们分别指向了上个步骤中生成的 SSH Key 私钥文件。至此,我们就完成了 SSH Key 的配置。

添加公钥

可以注意到,在上述配置文件中,PreferredAuthentications 这一项的值为 publickey,这表示平台将使用公钥来进行认证。所以,接下来,我们需要在 Github 以及 Gitlab 上添加对应的公钥:

为 Github 添加 SSH 公钥 为 Github 添加 SSH 公钥

为 Gitlab 添加 SSH 公钥 为 Gitlab 添加 SSH 公钥

这一点,在各个平台上基本上是相似的,通常都可以在设置中找到相应的选项,这里不再赘述。

身份验证

OK,现在我们可以来验证下 SSH Key 是否生效,以 Github 为例:

bash1 行
1
ssh -T git@github.com

如果你可以看到类似下面这样的回应,就证明这个 SSH Key 已添加成功,Gitlab 同理:

为 Github 添加 SSH 公钥 为 Github 添加 SSH 公钥

使用 SourceTree

到这一步,其实我们的目的就达到了,Git 客户端会根据项目里 Git 仓库的地址,来决定要使用哪一个 SSH Key。博主平时习惯使用 SourceTree,所以,这里我还想再补充一个点,那就是邮箱。众所周知,Git 里的配置有全局配置和本地配置两种,通常情况下,我们会使用下面的命令来配置全局用户:

bash2 行
12
git config --global user.name "<Your-Name>"
git config --global user.email <Your-Email>

而 SourceTree,默认使用全局用户,这无疑会令我们在工作和生活上的身份产生混淆。对此,我的建议是选取工作邮箱来配置全局用户,然后在个人项目里使用个人邮箱来配置本地用户,这样就不会在个人项目中泄露或者掺杂公司邮箱,这样可以有效地杜绝信息安全或者是知识产权方面的纠纷。我现在养成的一个习惯是,在 SourceTree 里提交代码的时候,会稍微留意一下下面的用户信息,这算是在本地配置了多个 SSH Key 以后的一个副作用啦!

本文完!

赞赏博主
相关推荐 随便逛逛
关于 Docker 容器配置信息的渐进式思考 作为一名软件工程师,作者经常使用各种配置文件如 YAML、Markdown、Dockerfile 等进行工作。作者认为程序员追求配置的动态灵活性是天经地义的事,却发现在 DevOps 理念流行后,程序员们常常要像运维一样处理各种配置文件,这使得编程工作变得繁琐。在探讨容器、配置文件和环境变量时,作者通过回顾不同阶段的实践,分享了对配置管理的思考。起初,作者通过Dockerfile将配置文件复制到容器中,但很快意识到不同环境需要不同的配置。随后尝试使用环境变量来实现动态配置,并使用工具`envsubst`来注入环境变量到配置文件中。然而这种方法需要重新构建镜像,作者随后采用将配置更新脚本放入`CMD` 或 `ENTRYPOINT` 指令中,以便通过重启容器来更新配置。尽管运维同事更倾向于使用 `sed` 命令,但这种方法增加了维护成本。作者提到了配置文件挂载到主机的方法,这使得修改主机上的配置文件可以即时更新容器内的配置。Docker Swarm 提供了一种管理配置文件的机制,而 Kubernetes 则使用 ConfigMap 来管理容器内的配置。作者认为容器内的配置管理应让配置与容器分离,即使动态生效而不是固化在容器中。文章最后,作者提出配置管理的关键在于找到变化与不变之间的平衡,反映出技术选择往往不是选择题而是填空题。作者幽默地以古代钱币的外圆内方比喻自己的技术态度,认为一心只想搞技术的想法真实且不做作,并欢迎大家在评论区交流想法。
在 Docker 容器内集成 Crontab 定时任务 本文介绍了在Linux中使用Crontab执行定时任务的基础知识,包括Crontab文件的格式和示例,以及如何通过编写脚本和设置Crontab定时任务来解决Kerberos票据过期的问题。作者还分享了在Docker容器内集成Crontab定时任务的方法,包括如何编辑Crontab文件、查看定时任务日志、处理环境变量等技巧。最后,提供了相关链接供进一步学习参考。
评论 隐私政策
评论
  • 按正序
  • 按倒序
  • 按热度
Powered by Waline v3.5.6