Why does git using ssh use git as a username

Question

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.

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.

Answer 1

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.

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.

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

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?

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.

You can see some of this negotiation happening by using ssh -v [email protected], 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/[email protected]: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: [email protected]
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] 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.

Update

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
    User git
    Hostname github.com
    IdentityFile ~/.ssh/id_github

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

Answer 2

Don't forget that you would not be able to actually open an interactive secure shell on the remote Git repositories hosting server:

1. You have no business executing any command you want on that server
2. Your account is never created anyway (because of 1.)
3. The only commands you should be interested in are Git commands (upload-pack, receive-pack, for implementing the git clone/pull/push you are doing.)

For all those reasons, the only account you need to request a remote shell for is an administrative account managing those Git remote repos, typically named 'git'.

Some of those server would use the ssh feature named 'forced command' (I presented it here for Gitolite, but it applies to GitLab too)
That means it knows your account name because it is written as a parameter of a forced command associated to your public key in the ~git/.ssh/authorized_keys, which keeps track of all the public keys authorized to open a (non-interactive) shell.
That is how the Git hosting service knows which accounts is making a Git request.