为什么使用ssh的git使用git作为用户名 [英] Why does git using ssh use git as a username

问题描述

这只是关于git函数的一般性问题。我找不到任何与此相关的git手册，也许我没有在正确的位置寻找。

This is just a general question about how git functions. I couldn't find anything in the git manual related to this, maybe I'm not looking in the right place.

使用git中的ssh链接进行克隆时服务器，它使用的用户名是git，而不是您尝试使用的密钥的用户名。为什么git会这样做，以及git如何知道应该使用哪个密钥对来验证连接。

When you clone using an ssh link from a git server, the username it uses is git, not the username of the key you are trying to use. Why does git do this and how is git able to tell which keypair that it should use to authenticate the connection.

推荐答案

使用git服务器的ssh链接克隆时，它使用的用户名是git，而不是您尝试使用的密钥的用户名。

When you clone using an ssh link from a git server, the username it uses is git, not the username of the key you are trying to use.

正确。原因是服务绑定到用户帐户，并且您需要以该用户的身份访问服务器才能调用该服务。这真的是SSH的一个特性，而不是Git - Git只是使用SSH作为传输。
此外，SSH - 因此Git - 对与SSH密钥关联的用户一无所知 - 只是它已被批准访问该帐户。这通常是通过Git用户的 authorized_keys 文件完成的，当您添加和删除用户时，Gerrit或Gitolite等工具将管理该文件。 authorized_keys文件允许指定特定命令在进行身份验证时运行，并且这些工具使用该功能与用户进行通信 - 然后应用程序将从那里确定权限。

Correct. The reason for this is that the service is tied to a user account, and you need to access the server as that user in order to invoke the service. This is really a feature of SSH and not of Git--Git is just using SSH as a transport. Also, SSH--and therefore Git--knows nothing about the user associated with the SSH key--just that it's been approved for accessing the account. This is usually done through the authorized_keys file for the Git user, and tools like Gerrit or Gitolite manage that file as you add and remove users. The authorized_keys file allows specifying a specific command to run when authenticated, and these tools use that feature to communicate the user--then the app determines the permissions from there.

为什么git会这样做，以及git如何知道应该使用哪个密钥对来验证连接。

Why does git do this and how is git able to tell which keypair that it should use to authenticate the connection.

<这里有一点误解。其中有些并不是Git，而是SSH。像Git这样的工具使用SSH作为传输工具，因为它完成了身份验证，保护网络活动的艰苦工作，并且拥有诸如ssh-agent之类的工具，可以更轻松地进行身份验证。为什么要重新发明轮子？

There's a bit of a misconception here. Some of this is not so much Git as it is SSH. And tools like Git use SSH as the transport because it's done the hard work of authenticating, securing network activity, and has tools like ssh-agent to make authentication easier. Why reinvent the wheel?

密钥对实际上由以下两种方式中的一种来决定：在〜/ .ssh / config （这就是我所做的），或者让 ssh 遍历可用的键并找出它。如果管理员设置了严格的规则，后者可能会导致问题，因为任何不起作用的密钥都会被视为验证尝试。大多数人没有一个以上的密钥，所以它通常不是问题。

The keypair is actually determined one of two ways: you specify it in your ~/.ssh/config (this is what I do), or you let ssh walk through the available keys and figure it out. The latter can lead to problems if the administrator has setup strict rules since any key that doesn't work will count as an authentication attempt. Most people don't have more than one key, so it's generally not a problem.

您可以通过使用 ssh -v [e-mail] ，或者任何你遇到的服务器：

You can see some of this negotiation happening by using ssh -v [e-mail], or whichever server you're going against:

OpenSSH_7.4p1, LibreSSL 2.5.0
debug1: Reading configuration data /Users/jszakmeister/.ssh/config
debug1: /Users/jszakmeister/.ssh/config line 286: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Control socket "/tmp/[e-mail]:22" does not exist
debug1: Connecting to github.com [192.30.255.113] port 22.
debug1: Connection established.
debug1: identity file /Users/jszakmeister/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/jszakmeister/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version libssh_0.7.0
debug1: no match: libssh_0.7.0
debug1: Authenticating to github.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [e-mail]
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: [e-mail] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [e-mail] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /Users/jszakmeister/.ssh/known_hosts:25
Warning: Permanently added the RSA host key for IP address '192.30.255.113' to the list of known hosts.
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/jszakmeister/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([192.30.255.113]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
PTY allocation request failed on channel 0
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
Hi jszakmeister! You've successfully authenticated, but GitHub does not provide shell access.
debug1: channel 0: free: client-session, nchannels 1
Connection to github.com closed.
Transferred: sent 2988, received 1868 bytes, in 0.2 seconds
Bytes per second: sent 19242.2, received 12029.6
debug1: Exit status 1

我不确定是否完全回答了您的问题，但我希望这有助于解决问题。

I'm not sure that entirely answers your question, but I hope it helps.

更新

SSH是一个非常强大的工具，它也有很多配置选项。你可以做的一件事是让你的生活更轻松一点，就是设置你的配置来应用你想要使用的用户名和密钥文件：

SSH is an extremely capable tool that also has a lot of configuration options. One thing you can do to make life a little easier is setup your config to apply the username and key file you want to use:

〜/ .ssh / config

Host gh
    Username git
    Hostname github.com
    IdentityFile ~/.ssh/id_github

您可以使用类似上面的内容来允许 git clone gh：foo / bar.git 实际上意味着 git clone [e-mail]：foo / bar.git 并使用不同的SSH密钥进行认证。我一直都在使用这个功能，而不仅仅是与Git相关的东西。

You could use something like the above to allow git clone gh:foo/bar.git to essentially mean git clone [e-mail]:foo/bar.git and use a different SSH key for authentication. I use this feature all the time, and not just for Git-related stuff.

这篇关于为什么使用ssh的git使用git作为用户名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！