Ubuntu gitlab:can';t push或clone在备份还原后要求输入git密码

Ubuntu gitlab:can';t push或clone在备份还原后要求输入git密码,ubuntu,gitlab,Ubuntu,Gitlab,我最近备份了我的gitlab,并在另一台机器上进行了恢复。 机器浏览得很好,我可以创建项目、创建团队等等 但是我不能从本地机器推到这台机器上,因为它需要“git密码”。现在我知道可能是身份密钥问题,所以我从服务器上删除了用户的旧密钥并添加了新密钥,但问题仍然存在 我试图检查ssh错误,但没有任何线索 ssh -vvvT git@192.168.1.91 OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012 debug1: Rea

我最近备份了我的gitlab,并在另一台机器上进行了恢复。 机器浏览得很好,我可以创建项目、创建团队等等

但是我不能从本地机器推到这台机器上,因为它需要“git密码”。现在我知道可能是身份密钥问题,所以我从服务器上删除了用户的旧密钥并添加了新密钥,但问题仍然存在

我试图检查ssh错误,但没有任何线索

  ssh -vvvT git@192.168.1.91
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.91 [192.168.1.91] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/brij/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/brij/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/brij/.ssh/id_rsa-cert type -1
debug1: identity file /home/brij/.ssh/id_dsa type -1
debug1: identity file /home/brij/.ssh/id_dsa-cert type -1
debug1: identity file /home/brij/.ssh/id_ecdsa type -1
debug1: identity file /home/brij/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "192.168.1.91" from file "/home/brij/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/brij/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA b0:3d:ef:ee:b4:8a:cb:47:e1:f2:a2:b6:da:ad:29:e5
debug3: load_hostkeys: loading entries for host "192.168.1.91" from file "/home/brij/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/brij/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host '192.168.1.91' is known and matches the ECDSA host key.
debug1: Found key in /home/brij/.ssh/known_hosts:1
debug1: ssh_ecdsa_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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/brij/.ssh/id_rsa (0xb7a6c760)
debug2: key: /home/brij/.ssh/id_rsa (0xb7a75188)
debug2: key: /home/brij/.ssh/id_dsa ((nil))
debug2: key: /home/brij/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,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: Offering RSA public key: /home/brij/.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 RSA public key: /home/brij/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/brij/.ssh/id_dsa
debug3: no such identity: /home/brij/.ssh/id_dsa
debug1: Trying private key: /home/brij/.ssh/id_ecdsa
debug3: no such identity: /home/brij/.ssh/id_ecdsa
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
git@192.168.1.91's password: 
=======================================================

更新-我发现在/home/git/.ssh中,文件authorized_keys丢失,而它在我备份的另一台服务器的同一位置可用 gitlab shell之间还有一个符号链接

gitlab shell->/opt/bitnami/apps/gitlab/gitlab shell/


这与此有关。

因为您没有明确提到,我不确定您是否备份和恢复SSH密钥。通常,您应该备份
~/.ssh/id\u rsa
(私钥)和
~/.ssh/id\u rsa.pub
(公钥)文件,否则需要重新生成ssh密钥并上载到Gitlab服务器

你提到:

我从服务器上删除了用户的旧密钥并添加了新密钥,但问题仍然存在

具体而言,这意味着您应该:

  • 使用
    ssh-keygen
    重新生成密钥对(默认为
    ~/.ssh/id\u-rsa
    ~/.ssh/id\u-rsa.pub
  • ~/.ssh/id\u rsa.pub
    上传到Gitlab服务器
如果您认为您确实这样做了,您可以按照以下说明再次检查所有内容:

  • 使用
    ssh-keygen-y-f~/.ssh/id\u rsa
    从公钥重新生成私钥
  • 检查步骤1生成的密钥是否与您的
    ~/.ssh/id\u rsa.pub
    密钥相同(电子邮件无关紧要)。如果它们不同,则重新生成密钥对并上载到Gitlab服务器
  • 检查Gitlab上的公钥是否与步骤1和2中的密钥相同
    通常,在这些检查之后,SSH密钥应该可以正常工作。

    我发现在/home/git/.SSH中,文件授权密钥丢失,而在我备份的另一台服务器上的同一位置,文件授权密钥可用。此外,gitlab shell之间还有一个符号链接

    gitlab shell->/opt/bitnami/apps/gitlab/gitlab shell/

    我创建了符号链接并重新启动了gitlab服务器。 工作起来很有魅力,但是对于我的所有用户,我们必须在服务器上更改他们的密钥,也许文件夹备份和还原不是移动服务器的正确方式,我花了2天时间解决了这个问题

    更新-我从旧服务器复制了授权密钥,现在用户也不必更改密钥。
    但现在他们会被要求更改服务器标识,linux用户将不得不删除已知的_hosts文件,并让其使用服务器的新已知主机标识重新生成,而windows用户则可以使用,因为他们将被要求替换标识,他们只需说“是”我确实在服务器上上传了密钥,甚至使用ssh-keygen-y-f~/。ssh/id\u rsa和密钥是相同的。gitlab服务器上的公钥也是相同的。我正在为如何修复它而疯狂清除已知的主机是我场景中的关键步骤。