CentOS 服务器 GitLab 的 Git SSH 远程登录失败问题解决过程 2020-02-23 / 3,050 次 / 快抢沙发 / 35

真正的理解与收获，是在一次次的问题解决过程中实现的。

前因：
最近云服务器上检测到有一个异常登录：以用户名 git 远程登录服务器的异常，而且提醒有密码被破解的可能性。我在想，我的服务器目前只有一个 root 账号，好像没有主动创建过用户 git 的账号，我去管理后台，通过相关命令行查看当前用户列表：cat /etc/passwd

git:x:994:991::/var/opt/gitlab:/bin/sh

从以上显示结果来看，还真的有一个 git 用户：上面结果的第一个 : 之前的就是登录用户名，看到后面 GitLab 字眼，我就明白了，原来是我安装了 GitLab，然后 GitLab 自动创建了 git 用户。那么为了解决 git 远程登录服务器的异常，是不是禁止 git 用户登录就可以了呢，那么我们直接通过修改或者追加以下位置文件：/ect/ssh/sshd_config，禁止 git 用户远程登录。备注：想要使得这个修改配置生效，可以通过命令行重启 SSH 服务：service sshd restart。

DenyUsers git

从这以后就没有服务器后台提醒的以用户名 git 远程登录服务器的异常了，以为没有什么问题了，结果过了两天，有人通过 ssh 形式访问 GitLab，代码提交不上去，这个时候问题就来了。

git --no-optional-locks -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags origin refs/heads/ifeegoo:refs/heads/ifeegoo 
Pushing to git@***.git
Permission denied, please try again.
Permission denied, please try again.
git@***: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Pushing to git@***.git
Permission denied, please try again.
Permission denied, please try again.
git@***.com: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Pushing to git@***.git
Permission denied, please try again.
Permission denied, please try again.
git@***: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Pushing to git@***.git
Permission denied, please try again.
Permission denied, please try again.
git@***: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Completed with errors, see above

我核查了一下 GitLab 运行情况，没有发现异样，而且上报的同学自己本地配置了多个 SSH public key 和 private key，同时有一些因素干扰了我的判断，让我觉得应该是他那边的问题，试了好久也没有试出来，然后提醒说可能是服务器要做出调整，我也回想起来，我对服务器的操作，就是禁止了 git 用户远程登录了，难道和这个有关？而且同学们通过用户名和密码形式访问 GitLab 仓库是没有问题，另外我记起来 Git SSH 形式访问的地址是 git@ 打头，这个应该就是可以理解为：以 git 用户身份通过 SSH 形式远程登录到服务器！于是我通过测试，取消禁止 git 通过远程登录，这个问题就解决了。但是，如果取消这个禁止，那么服务器又会安全警告，于是通过 Google 可以发现以下问题：

通过 Google 找到的答案都是通过修改：/etc/passwd 这个文件，将里面下面这段最后一个冒号后面的内容修改成 Git Shell 的目录：

//初始
git:x:994:991::/var/opt/gitlab:/bin/sh
//修改成
git:x:994:991::/var/opt/gitlab:/usr/bin/git-shell

修改了之后发现还是有问题，无法解决通过 Git SSH 形式访问远程代码仓库，我在想是不是这个路径下的 Git Shell 不存在，通过查找，我们的服务器里面根本就不存在 /usr/bin/git-shell，通过命令行查找其他地方的 git-shell，也不存在，网上说通过手动安装的 Git 在 CentOS 服务器中，就是那几个默认的路径了。我想到：我就没有单独手动安装过 Git，Git 应该是在安装 GitLab 的时候附带安装的。 这种安装一般都是内嵌的形式：embedded 形式，我们去找到 GitLab 相关的文件夹：

/opt/gitlab holds application code for GitLab and its dependencies.

/var/opt/gitlab holds application data and configuration files that gitlab-ctl reconfigure writes to.

/etc/gitlab holds configuration files for omnibus-gitlab. These are the only files that you should ever have to edit manually.

/var/log/gitlab contains all log data generated by components of omnibus-gitlab.

通过 GitLab 的安装目录底下找到这个：/opt/gitlab/embedded/bin/git-shell，那看目录结构应该就是这个，于是修改 /etc/passwd 这个文件，将里面下面这段最后一个冒号后面的内容修改成 Git Shell 的目录。备注：这个文件的修改不需要通过命令行来生效，修改完了之后保存文件直接生效。

//初始
git:x:994:991::/var/opt/gitlab:/bin/sh
//修改成
git:x:994:991::/var/opt/gitlab:/opt/gitlab/embedded/bin/git-shell

然后果然还是不行！应该说没有错啊，到底是哪里的问题？越是这个时候，越要注意细节，不要慌乱，因为成功的钥匙马上就要拿到了，不要放弃。我们再去看 Git 执行的错误日志提醒，我们发现了一个非常重要的信息：fatal: unrecognized command ‘/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-42’。原来他是执行了 gitlab-shell，应该是 GitLab 内部针对 Git Shell 有一层封装，走的是 GitLab Shell。

git --no-optional-locks -c color.branch=false -c color.diff=false -c color.status=false -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree push -v --tags origin refs/heads/ifeegoo:refs/heads/ifeegoo 
Pushing to git@***.git
fatal: unrecognized command '/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-42'
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Completed with errors, see above

我们再去修改 /etc/passwd 这个文件：

//初始
git:x:994:991::/var/opt/gitlab:/opt/gitlab/embedded/bin/git-shell
//修改成
git:x:994:991::/var/opt/gitlab:/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell

然后这次真的成功啦！经过以上整个过程的思考探索，我们终于解决了：由于禁用了 Git 用户远程 SSH 登录导致的 GitLab 的 Git 无法通过 SSH 形式远程访问代码仓库，同时解决 git 用户远程登录执行操作的风险。我觉得这个过程总结如下：
1.真正的理解与收获，是在一次次的问题解决过程中实现的。
说明：以前对于 Git 的 SSH 远程代码仓库地址的理解比较肤浅，以为以 git@ 这种打头格式，只是为了区分 http 方式，而没有理解为其实是以 git 用户名来通过 SSH 远程登录服务器的这种背后技术逻辑，虽然以前通过命令行的形式有 username@server 形式登录过服务器，但是没有想到 git@ 也是同样的道理。
2.类比比较思考很重要。
我在解决这个问题的时候，发现网上基本上清一色的都是手动安装的 Git，并没有提到通过安装 GitLab 的方式自带安装的 Git，同时 GitLab Shell 在某种程度上封装执行了 Git Shell 这些，如果我没有进一步的类比和比较，那么我最后也不会知道差一点，可能直接停留在修改 /usr/bin/git-shell 那一步，就推进不了了。
3.遇到问题和解决问题过程中，一定要不断尝试，不断对比，得到最关键的正确合理的步骤和知识体系。
说明：很多时候，我们解决了一个问题，但是不知道这个问题为什么被解决了，只是一知半解，甚至是稀里糊涂的解决的，不知道为什么，那么这种解决问题的过程和花费在这个问题上的精力，是一种很大的损失和浪费。例如我在网上找到的博客里面，很多仅仅是直接记录一个修改成 /usr/bin/git-shell，为什么要修改这个，为什么要指向 Git Shell，这个目录如何通过命令行或者手动方式来确认这个 Git Shell 路径是否存在，是否被调用。并没有进一步的去阐释和说明。
4.所有的问题解决，最终是形成我们的解决问题的思考逻辑，方式方法，性格塑造。
说明：无论是生活，工作，还是学习，有一个非常重要的共同点，那就是：解决问题的能力。如果我们不能够在解决同样的问题中，获得类似问题的解决能力，方式方法，那么我们最终还是会停留在最基础的层次，下次遇到了此类问题，不知道如何解决，或者还是稀里糊涂的解决，不利于我们融会贯通和能力的提升。

上一篇： « 读书笔记 1 ：《读懂一本书-樊登读书法》 下一篇： 远程办公：值得企业考虑的办公方式 »