在Ubuntu服务器上，'foo.com'，为gitlab提供服务，一个gitlab用户，'bar'，可以克隆，推送和拉取而不必使用密码，没有问题（公钥设置在用户'bar'的gitlab服务器。）。
用户'bar'想要使用服务器'foo'上的命令行，并ssh bar@foo.com。当用户'bar的ssh键不在'foo'的authorized_keys中时，'bar'会暂时记录到Gitlab中：
debug2: shell request accepted on channel 0
Welcome to GitLab, bar
然后该会话立即退出。
当用户'bar的ssh密钥 - 即使是未在GitLab中注册的密钥 - 位于'foo.com'的authorized_keys中时，该用户在执行ssh bar@foo.com时获得预期结果。但是，用户bar（在他们的本地计算机上）无法从他们的gitlab管理的存储库中推送，拉取，克隆等，错误消息是“'some-group / some-project.git '似乎不是一个git存储库“。
似乎存在配置错误，因此shell访问与gitlab项目访问混淆。
用户'foo'如何能够通过ssh登录到常规shell提示符并且还能正常使用git（从本地盒子中与远程git服务器交互）？
答案 0 :(得分：1)
经过大量的搜索后，我才知道为什么会发生这种情况。我遇到过同样的问题。我想使用相同的SSH密钥进行SSH登录以及GitLab访问。
我发现这个帖子很有帮助： 的 https://gist.github.com/hanseartic/368a63933afb7c9f7e6b
在 authorized_keys 文件中，gitlab-shell输入特定命令来限制访问。一旦用户通过Web界面输入公钥，它就会增加限制。它使用command选项来执行此操作。
我们需要修改command选项以允许访问bash，并记住如果在逗号分隔部分中列出，请删除no-pty选项。例如，在我的情况下，我在行内no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ，并且必须从列表中删除no-pty。
示例修改后的命令应如下所示：
command="if [ -t 0 ]; then bash; else /home/ec2-user/gitlab_service/gitlab-shell/bin/gitlab-shell key-11; fi",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAA...
需要注意通过检查密钥编号或与该命令关联的公钥和用户名来编辑正确的命令。
这不需要重启任何服务。