GitLab - 不接受通过 SSH 推送 [要求输入 SSH 密码],可以与 HTTP 一起使用吗?

GitLab - 不接受通过 SSH 推送 [要求输入 SSH 密码],可以与 HTTP 一起使用吗?

我已经研究了该问题的多种解决方案,包括: https://serverfault.com/questions/515395/gitlab-unable-to-push-via-ssh Gitlab 无法使用 SSH 密钥 http://community.bitnami.com/t/unable-to-make-a-ssh-connection-to-gitlab-but-http-push-and-clone-are-working/14939


好的,那么...我今天刚刚安装了 GitLab。我遵循本手册。当我创建用户时,“git”正在使用中,因此我决定使用“gitlab”。如果这是一个错误的决定,我可以回过头来尝试查看哪些用户在使用“git”以及原因,以及我是否可以停止使用并将其交给 GitLab。

基本上,当我推送 GitLab 时,我会尝试使用 SSH 地址:[电子邮件保护]:user/repo。当我使用“git push origin master”(origin 指向上述地址)时,系统会要求我输入用户“gitlab”的 SSH 服务器密码。如果我输入密码,GitLab 会告诉我“user/repo”似乎不是存储库,然后退出。

“ssh -vvvT”的输出是:

C:\Users\Jake>ssh -vvvT [email protected]
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug2: ssh_connect: needpriv 0
debug1: Connecting to git.redacted.com [redacted] port 22.
debug1: Connection established.
debug1: identity file /c/Users/Jake/.ssh/identity type -1
debug3: Not a RSA1 key file /c/Users/Jake/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /c/Users/Jake/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /c/Users/Jake/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /c/Users/Jake/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubu
ntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g
roup-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: [email protected],ecdh-sha2-nistp256,ecdh-
sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hel
lman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour12
8,[email protected],[email protected],[email protected],ae
s128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndae
[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour12
8,[email protected],[email protected],[email protected],ae
s128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndae
[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],um
[email protected],[email protected],[email protected],hma
[email protected],[email protected],hmac-sha1-96-etm@opens
sh.com,[email protected],hmac-md5,hmac-sha1,[email protected],umac-1
[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh
.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],um
[email protected],[email protected],[email protected],hma
[email protected],[email protected],hmac-sha1-96-etm@opens
sh.com,[email protected],hmac-md5,hmac-sha1,[email protected],umac-1
[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh
.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 119/256
debug2: bits set: 524/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /c/Users/Jake/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /c/Users/Jake/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'git.majornoob.com' is known and matches the RSA host key.
debug1: Found key in /c/Users/Jake/.ssh/known_hosts:1
debug2: bits set: 515/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /c/Users/Jake/.ssh/identity (0x0)
debug2: key: /c/Users/Jake/.ssh/id_rsa (0xa01b360)
debug2: key: /c/Users/Jake/.ssh/id_dsa (0xa01b378)
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /c/Users/Jake/.ssh/identity
debug3: no such identity: /c/Users/Jake/.ssh/identity
debug1: Offering public key: /c/Users/Jake/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /c/Users/Jake/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

C:\Users\Jake>

这似乎是读取我的 SSH 密钥时遇到的问题?我不确定发生了什么。

我使用以下命令尝试了两种具有两种不同加密类型的两个不同的 SSH 密钥:

ssh-keygen -t rsa -C "[email protected]"
ssh-keygen -t dsa -C "[email protected]"

如果我尝试使用 SSH 协议推送,则输出如下:

C:\Users\Jake\Documents\Development\test>git push origin master
[email protected]'s password:
fatal: 'jake/test.git' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

C:\Users\Jake\Documents\Development\test>

为什么它甚至要求输入 SSH 密码?我希望它使用密钥。

密钥位于 GitLab 安装上,以下是一些证明: SSH密钥

我不确定接下来该怎么做,或者我可以提供哪些其他信息来更轻松地诊断我的问题。请帮帮我!我会回答您提出的任何问题,以便让您更轻松地修复此问题。

先感谢您!


编辑:当我使用“ssh -vvvT[电子邮件保护]“当我实际输入用户密码时,它会显示 Ubuntu MOTD。我百分之百确定这不会发生。

答案1

你是对的。MOTD 应该不是向任何用户显示。Gitlab 有自己的内置 shell 来处理用户,但该 shell 仅在用户使用其私钥登录时运行,这对您不起作用。因为使用密码以 git 身份登录会带您进入提示符,所以您应该删除 git 的密码:

sudo passwd -d git

然后通过运行禁用使用 bash 登录sudo vim /etc/passwd,找到 git 用户,并在末尾/bin/bash将 替换为/bin/nologin

至于密钥,请确保您的客户端计算机可以使用密钥。尝试 ssh 到 localhost。它应该要求输入密码。注销,使用以下命令将客户端的 ssh 密钥添加到自身:

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys #This should not require root

然后尝试再次登录 localhost。如果它不要求输入密码,则说明您的客户端设置正确。

如果您的客户端没有问题,请尝试调试服务器。如果你这样做,请从屏幕截图中删除你的密钥。然后,通过运行确保 Gitlab 对 /home/git/.ssh 目录具有完全访问权限sudo chmod -R git /home/git/.ssh。重新添加你的密钥,然后运行sudo cat /home/git/.ssh/authorized_keys并查看你的密钥是否在那里。

如果这不起作用,请通过运行检查您的 gitlab 日志tailf /home/git/gitlab/{LOG}.log,然后替换{LOG}unicorn、、或,然后尝试添加您的密钥applicationproductiongithost

请记住在做任何事情之前删除你的密钥。密钥存储在数据库中,并且应该存储在 /home/git/.ssh/authorized_keys 中。如果它们在数据库中,但不在文件中,则可能会出现问题。

答案2

我的情况

服务器:Ubuntu 14.04.1 更新到最新的软件包版本 (sudo apt-get update && sudo apt-get dist-upgrade)。Gitlab:6.9.0(gitlab 版本其实并不重要)。

在升级和重启服务器之前,一切都运行正常,ssh 密钥和所有相关内容都正确。但在升级软件包之后,所有用户都无法进行正常操作,而是要求输入用户“git”的密码。

我做了什么?

几个小时后,我确实发现了真正发生的事情:/home/git运行 git 命令时对目录进行新的权限检查。

检查其是否适合您的情况的步骤:

  1. tail -f /var/log/auth.log
  2. 尝试执行 git 操作(如git remote update)。
  3. 检查日志文件。出现如下一行:Authentication refused: bad ownership or modes for directory /home/git
  4. 确保 git 专有/home/gitsudo chown git:git /home/git
  5. 确保目录权限:sudo chmod 755 /home/git
  6. 放入 git 存储库并执行,git remote update没有任何问题。

这对我有用!

相关内容