企业官网建设流程全解析

1. 为什么折腾多账号 SSH 管理：一个开发者的日常困境

先说说我自己的情况。我平时负责的几个项目分别托管在不同平台，公司内部项目放在私有 GitLab 上，开源项目和个人 Demo 放在 GitHub，部分国内业务相关代码则放在 Gitee。时间一长，问题就来了——每次切换项目，都得换 SSH key 或者反复配置用户信息，甚至有时候提交记录里用户名和邮箱都对不上，代码归属全乱了。

你可能也遇到过类似的场景：同一台电脑上，既要用 GitHub 拉取开源项目，又要往公司服务器推送代码，还想管理个人的某个仓库。默认情况下，SSH 只认一套密钥，git 也只认一个全局用户身份。这就是多平台、多账号管理的核心痛点。

这个问题的本质，在于 SSH 客户端如何选择密钥，以及 Git 如何匹配用户身份。只要搞懂这两件事，多账号管理并不复杂，不需要安装任何额外工具，也不需要改全局配置，只用系统自带的 SSH config 机制就能解决。

这篇文章适合所有在本地开发中需要同时对接多个代码托管平台的开发者，无论你是前端、后端还是运维，只要你的电脑上要同时使用 GitHub、Gitee、GitLab 或自己的服务器，都可以参考这套方案。

2. 核心思路：SSH 别名机制与 Host 区分原理

2.1 SSH config 是怎么工作的

SSH 客户端在连接远程主机时，默认读取~/.ssh/config文件。这个文件的核心作用，是把一个你自定义的“别名”映射到真实的远程主机地址、端口、用户名和私钥文件。

举个例子，默认情况下你执行git clone git@github.com:xxx/repo.git，SSH 会找~/.ssh/id_rsa这个默认私钥去连接 github.com。如果你在 config 里写了一段配置，把github.com这个 Host 指向另一个私钥文件，那么SSH 连接时就会用你指定的那把钥匙。

多账号管理的思路其实很简单：为每个平台（甚至每个账号）生成独立的密钥对，然后通过 config 文件里的 Host 别名做区分。比如你想用个人账号连接 GitHub，就用git@github-personal这样一个别名，SSH 会自动选择对应的私钥。

2.2 一个 Host 一个身份的关键

有些教程会让你直接改~/.ssh/config里 github.com 的私钥指向，这样全局只有一个 GitHub 身份。但如果你想在两个 GitHub 账号之间切换，这种方案就失效了。

正确做法是：每个平台、每个账号都拥有独立的 Host 条目。它们看起来像是不同的“主机”，实际上是同一个地址，只是走了不同的私钥和用户身份。

关键点在于 Git 命令中的 URL 格式。普通地址是git@github.com:user/repo.git，使用 Host 别名后则变成git@github-personal:user/repo.git。这里的github-personal不是真实域名，只是 config 中定义的映射名，SSH 会读配置然后真正连接github.com，但使用的是指定私钥。

这套机制的巧妙之处在于，Git 本身并不关心你连接的是哪个平台，它只负责把 SSH 的地址传给 SSH 客户端。真正做身份区分的是 SSH 层，而不是 Git 层。

提示：理解了这个原理，后面所有配置都不会再让你困惑。所以不要跳过这一段，多花两分钟想清楚，胜过半小时瞎试。

3. 多账号环境准备：生成密钥对与配置 SSH config

3.1 生成独立的 SSH 密钥对

在开始之前，先确认本机是否已有 SSH 密钥。执行下面这条命令查看：

ls -l ~/.ssh/

如果看到id_rsa和id_rsa.pub，那是你之前生成的默认密钥。在多账号方案里，建议为每个平台单独生成密钥，不要共用。

比如我要配置 GitHub 和 Gitee 两个平台，我先生成两对密钥：

# 为 GitHub 生成密钥，注释里标注用途 ssh-keygen -t rsa -b 4096 -C "github-main@example.com" -f ~/.ssh/id_rsa_github # 为 Gitee 生成密钥 ssh-keygen -t rsa -b 4096 -C "gitee-main@example.com" -f ~/.ssh/id_rsa_gitee

参数说明：

• -t rsa指定密钥类型，目前 RSA 兼容性最好。
• -b 4096指定长度，4096 位安全性更高。
• -C是注释，通常会写上你的邮箱，方便辨认。
• -f指定生成的文件路径和名字，这一步非常关键，决定了后续 config 怎么指向。

执行过程中会提示你设置 passphrase（密码短语），可以直接留空。如果设置了，每次 SSH 连接都要输入一次密码，比较麻烦。当然，安全要求高的场景建议设置，配合 ssh-agent 使用可以做到只在登录时输入一次，后面我会简单提一下。

3.2 编写 SSH config 文件

密钥生成好之后，开始编辑~/.ssh/config。如果文件不存在，先创建：

touch ~/.ssh/config vim ~/.ssh/config

下面是一个完整的双平台配置示例：

# GitHub 主账号 Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github # Gitee 主账号 Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_rsa_gitee

如果你要在同一个平台上区分多个账号，比如两个 GitHub 账号，需要这样写：

# 第一个 GitHub 账号（默认） Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github_main # 第二个 GitHub 账号（使用别名 github-work） Host github-work HostName github.com User git IdentityFile ~/.ssh/id_rsa_github_work

配置项的含义并不复杂：

• Host是别名，也就是你在 Git 地址里看到的名称。
• HostName是真实连接的域名。
• User固定填git，因为 Git 平台统一用这个用户。
• IdentityFile指向该账号对应的私钥。

写完配置文件后，立刻测试一下 SSH 连接是否正常。

3.3 测试连接并添加公钥到平台

先测试 GitHub：

ssh -T git@github.com

如果配置正常，你会看到类似下面的提示：

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

这说明 SSH 已经识别了你，并且正确匹配到了账号。同理测试 Gitee：

ssh -T git@gitee.com

Gitee 的返回信息类似：

Hi 用户名! You've successfully authenticated, but Gitee does not provide shell access.

如果提示权限拒绝，先检查公钥是否已经添加到平台上。

添加公钥的步骤很简单：查看你的公钥内容，复制到对应平台的 SSH Keys 设置页面。

cat ~/.ssh/id_rsa_github.pub cat ~/.ssh/id_rsa_gitee.pub

把公钥分别添加到 GitHub 的 Settings -> SSH and GPG keys，以及 Gitee 的设置 -> SSH 公钥。这一步不需要什么技术含量，但要注意别把公钥弄混了，加到错误的平台上。

注意：添加公钥时复制的内容要以ssh-rsa开头，包括后面的注释邮箱，都是完整的字符串。复制少了会导致认证失败。

4. 平台侧配置与仓库操作：更换 remote 地址与用户信息

4.1 给仓库配置独立的用户信息

SSH 解决了“你是谁”的问题，但 Git 提交记录里的用户名和邮箱是独立于 SSH 的另一套配置。很多人配置了 SSH 之后提交代码，发现提交者还是全局用户信息，原因就在这里。

默认情况下，Git 使用全局配置里的用户信息，查看方式：

git config --global user.name git config --global user.email

如果你所有平台的账号用户名和邮箱都一样，那不用改，全局配置就够了。但我的场景是 GitHub 用一个个人邮箱，Gitee 用另一个工作邮箱，这就需要在每个仓库目录下手动配置。

在仓库目录下执行：

git config user.name "你的GitHub用户名" git config user.email "你的GitHub邮箱"

注意，不加--global参数，只影响当前仓库。这个配置存在仓库的.git/config里，不会干扰其他项目。

更好的做法是：如果你某个目录下的项目都归属于同一个账号，可以在用户的~/.gitconfig里加入条件配置。比如我所有在~/work/目录下的项目都用工作邮箱，可以这样写：

[includeIf "gitdir:~/work/"] path = ~/.gitconfig-work

然后在~/.gitconfig-work里写：

[user] name = 工作账号名 email = work@example.com

这套条件配置非常实用，减少了很多手动操作。前提是你的项目目录结构比较有规律，能按文件夹区分身份。

4.2 克隆仓库时正确使用别名地址

配置完 SSH 和用户信息，接下来就是实际操作。克隆仓库时，GitHub 的默认地址是：

git clone git@github.com:username/repo.git

Gitee 的默认地址是：

git clone git@gitee.com:username/repo.git

如果你在 config 里为第二个 GitHub 账号设置了别名github-work，克隆它的仓库时要用：

git clone git@github-work:username/repo.git

这里的核心区别是github.com换成了github-work，后面的路径（username/repo.git）保持不变。

如果你已经用默认地址克隆了仓库，想切换到别名身份，可以这样改 remote：

git remote set-url origin git@github-work:username/repo.git

查看当前 remote 地址确认无误：

git remote -v

改完之后，重新执行git push或git pull，SSH 就会自动使用新别名对应的私钥了。

提示：如果仓库里的提交记录已经用了错误用户名，后续我会在排查部分说怎么批量修改历史提交信息。不过这是紧急手段，最好一开始就配好，避免麻烦。

4.3 让 ssh-agent 帮你记住密钥（可选但推荐）

如果你给密钥设置了 passphrase，或者你的私钥文件不是默认的id_rsa，可能每次连接都会提示你输入密码或确认密钥。

用 ssh-agent 可以解决这个问题，把密钥加载到内存，之后一段时间内免密操作。

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa_github ssh-add ~/.ssh/id_rsa_gitee

在 macOS 上，你还可以把ssh-add --apple-use-keychain配合 Keychain 使用，实现重启后依然免密。Linux 下可以开启 ssh-agent 服务并设置开机自启。

不过说实话，如果你嫌麻烦，直接不设置 passphrase 最省事。安全性嘛，私钥文件本身有本地文件权限保护，只要不泄露，对个人开发场景基本够用。

5. 多平台多账号实操演练：GitHub + Gitee 双平台配置全流程

5.1 我的实际配置记录

我在这台电脑上的实际配置，正好是 GitHub 加 Gitee 双平台，外加一个私有 GitLab。我按下面的步骤完完整整走了一遍，你可以把它当作参考模板。

检查一下最终的 config 文件状态：

cat ~/.ssh/config

输出内容是这样的：

# 用于 GitHub 个人项目 Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github # 用于 Gitee 个人项目 Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_rsa_gitee # 用于公司 GitLab Host gitlab-company HostName gitlab.company-domain.com User git IdentityFile ~/.ssh/id_rsa_gitlab Port 2222

注意最后一项，公司 GitLab 如果改了 SSH 端口，需要在配置里指定Port。这个问题我踩过坑，下面排查部分会细说。

5.2 验证测试与权限确认

配置完并添加公钥后，我逐个测试连接：

ssh -T git@github.com ssh -T git@gitee.com ssh -T git@gitlab-company

三条命令分别返回了欢迎信息，说明配置无误。这里有个小细节：在测试 Gitee 时，返回的欢迎语是中文的，不要慌，看到successfully authenticated或类似字样就说明通了。

接下来我在电脑上同时克隆了三个仓库，分别验证拉取和推送：

git clone git@github.com:myaccount/blog.git git clone git@gitee.com:myaccount/blog-mirror.git git clone git@gitlab-company:team/project.git

推送时分别往各自仓库写了几个测试提交，确认提交记录里显示的用户名和邮箱都是正确的。

5.3 本地用户身份确认

在仓库目录下执行：

git config user.name git config user.email

我分别在三个仓库里检查，结果如下：

这样就实现了“一台电脑、三套身份”互不干扰。

6. 常见问题与排查技巧实录

6.1 SSH 权限拒绝或 Permission denied

这是最常见的问题。执行ssh -T git@github.com时报Permission denied (publickey)，排查思路按顺序来。

第一步，确认私钥路径是否正确。执行：

ssh -vT git@github.com

会打印详细的调试信息。重点看debug1: Offering public key这一行，后面跟着的私钥路径是不是你预期的那个。如果显示的路径是~/.ssh/id_rsa而不是你配置的id_rsa_github，说明 config 文件没生效或者权限不对。

第二步，检查~/.ssh/config文件权限。SSH 客户端很挑剔，如果配置文件权限过于开放，它会直接忽略：

chmod 600 ~/.ssh/config chmod 700 ~/.ssh chmod 600 ~/.ssh/id_rsa_github

第三步，确认公钥已经添加到平台。有时候公钥复制不全，或者添加到了另一个账号下，都会导致认证失败。重新登录平台，检查一下 SSH keys 列表。

6.2 使用别名后提示 Host key verification failed

第一次连接新的 Host 时，SSH 会询问你是否信任这台主机，并写入~/.ssh/known_hosts。如果你在 config 里用了别名，它会把别名和真实主机分别记录。

如果之前用github.com连接过，现在换成github-work，可能会提示 host key 不匹配。最简单的办法是手动删除 known_hosts 里对应的旧条目：

ssh-keygen -R github.com ssh-keygen -R github-work

然后重新连接，按提示输入 yes 接受新的 host key。这个方法也适用于服务器主机密钥更换后的连接问题。

6.3 推送代码时提示仓库不存在或没有权限

这个问题通常出现在同一平台多账号的场景。你的私钥匹配了新账号，但仓库路径还是旧账号的。

比如你本来想推送git@github.com:newwork/repo.git，但写成git@github.com:oldaccount/repo.git，自然没有权限。用别名时更容易混淆，所以克隆仓库时一定要看清路径里的组织名或用户名。

还可以检查一下 remote 地址是否用了别名：

git remote get-url origin

如果发现地址不对，重新设置：

git remote set-url origin git@github-work:correct/repo.git

6.4 提交记录里用户名显示不对

SSH 认证没问题，但推送后发现提交作者不是自己，这是用户信息配置的问题。检查当前仓库的配置：

git config user.name git config user.email

如果显示的是全局配置里的信息，而你想用另一个账号，执行前文说过的本地配置方法修改。

如果已经有一批提交使用了错误信息，需要批量修正。假设最近 5 次提交需要改：

git rebase -i HEAD~5

在编辑器中把需要修改的提交标记为edit，然后逐个执行：

git commit --amend --author="正确用户名 <正确邮箱>" --no-edit git rebase --continue

操作前确保这些提交还没推送到远程，否则需要强推，容易影响协作成员。

注意：如果提交已经推送且别人拉取过，不要直接改历史。最好新开分支处理，或者追加一条修正提交，避免把仓库搞乱。

6.5 config 文件配置生效顺序的坑

SSH config 的匹配规则是：从上到下逐条匹配，使用第一个匹配到的 Host 条目。这意味着如果前面有一个宽泛的Host *配置，后面的具体配置可能不会被执行。

举个例子：

Host * IdentityFile ~/.ssh/id_rsa_default Host github.com IdentityFile ~/.ssh/id_rsa_github

这种情况下连接 github.com 时，会用id_rsa_default而不是id_rsa_github，因为第一条Host *已经匹配成功。解决办法是把具体配置放在前面，或者不要在Host *里写死 IdentityFile。

我自己的配置文件里，Host *只放了通用参数，比如连接超时和重试次数，具体密钥全部放在各平台条目里，从源头上避开这个坑。

6.6 公司内网 GitLab 换了端口或域名

有些公司 GitLab 不走默认 22 端口，而是用 2222 或者其他端口。这种情况下克隆地址会变，如果 SSH 连不上，看看 config 里是否加了 Port。

如果 GitLab 域名走的是内网 DNS，有时候 SSH 会解析失败。可以尝试在 config 里把 HostName 写成 IP 地址，但要注意 IP 变化时需要更新配置。

这个场景下排查方法依然是ssh -vT，debug 信息里会显示实际连接的 IP 和端口，确认是否和预期一致即可。

7. 一些提升效率的小技巧

7.1 为不同用途生成专用密钥，而不是到处复用

我看到很多人为了省事，一把id_rsa.pub复制到所有平台。这样做短期能跑通，但一旦某个平台泄露了这把公钥，或者你想单独撤销某个账号的访问权限，就得全局换密钥，牵连所有平台。

正确思路是：每个平台一把密钥，甚至你的私人电脑和公司电脑各用不同的密钥。撤销某一把密钥时，不影响其他平台登录。

7.2 用别名区分不同用途的 GitHub 账号

如果你有两个 GitHub 账号，一个用于个人开源，一个用于公司项目，可以建两个别名，比如github-personal和github-work。

这样做的好处是，你看到仓库地址里的别名，就知道当前用的是哪个身份，不会稀里糊涂推错仓库。

配置示例：

Host github-personal HostName github.com User git IdentityFile ~/.ssh/id_rsa_github_personal Host github-work HostName github.com User git IdentityFile ~/.ssh/id_rsa_github_work

克隆时分别使用：

git clone git@github-personal:myaccount/pet-project.git git clone git@github-work:companyname/internal-tool.git

7.3 定期检查密钥文件与 known_hosts

我的习惯是每隔一段时间查看一下~/.ssh/目录，确认密钥文件没有意外变更，known_hosts 里有没有异常的主机记录。

如果你用ssh -T提示的主机信息和你预期不符，优先怀疑 DNS 被劫持、或者 known_hosts 里残留了旧的主机密钥。清理方法前文已经给过，这里不再重复。

7.4 用 GitHub 或 Gitee 的 SSH 密钥管理页面做定期清理

很多人的 SSH 公钥列表里积累了一堆不知名的 key，有的是几年前的测试机器，有的已经换电脑了。把这些废弃 key 删掉，能有效提升账号安全性。

具体做法：登录平台设置页面，找到 SSH keys 列表，对比本地~/.ssh/*.pub文件的指纹，不匹配的果断删掉。

8. 最后的体会与建议

这套多账号 SSH 管理方案，我在不同电脑上反复配置过好几遍，从最初的照猫画虎到后来完全弄懂了原理，中间确实踩了不少坑。回头来看，最核心的收获不是记住几条命令，而是理解了 SSH 别名和 Git 用户信息这两层独立逻辑的关系。

配置过程中我最大的体会是：不要想当然地认为改一下 Git 的全局用户信息就能区分不同平台的提交身份。SSH 管的是网络连接层的认证，Git 管的是提交元信息层的身份，两者各管各的，必须同时配好才能真正做到多账号互不干扰。

如果你第一次配置失败了，不要急着删了重来。用ssh -vT看 debug 日志，它会清楚地告诉你每一步做了什么，密钥用的是哪个，服务器返回了什么。这些信息比任何教程都更有针对性。

最后再分享一个小技巧：我习惯把配置好的~/.ssh/config文件纳入自己的版本管理备份仓库（注意不要把私钥传上去，只同步 config 和公钥）。这样换了新电脑，几分钟就能恢复整套配置，不用再凭记忆敲一遍。公钥本身不是敏感信息，config 里包含的路径和端口也算是半公开信息，但为了稳妥起见，建议把配置文件放在私有仓库里。

希望这篇文章对你有帮助。如果在这套配置过程中遇到其他奇怪的问题，建议先用ssh -vT定位，再结合 config 匹配规则去推，大概率都能找到原因。