Why can a public key for a user named “user” be used for a remote Git repository with a user named “git?”

Question

SOLVED !

A combination of small things was causing this

1. My initial misconception re ssh keys being specific to users
2. Two things were giving hard-to-understand results in my testing:
   • I discovered my ssh passphrase was incorrect for one key, working on the other (check this with "$ssh-keygen -y")
   • on the command line, ssh needs -i NOT -I to specify a key (duh)
3. My config file as suggested.

Thank you to everyone for the help, much appreciated.

---

I am setting up a Git repository on my local network using SSH authentication. I followed the instructions found here on the official Git website: “Git on the Server - Setting Up the Server”

Trying to find some background to how it should work and why this setup is not working.

I am running Linux Mint 20 at the user workstation end, CentOS 7.1 on the Git server side.

I can SSH as user from my-workstation to gitserver using public key authentication.

Copy SSH keys for user from my-workstation to the Git users .ssh directory on gitserver:

root@gitserver/srv # ls -l  
drwxrwx---. 7 git  git  4.0K 06/01/21 08:35 git
root@gitserver/srv # ls -ld git/.ssh/
drwx------. 2 git git 28 Jan  3 12:12 git/.ssh/
root@gitserver/srv # ls -l git/.ssh/
-rw-------. 1 git git 1.8K 03/01/21 21:45 authorized_keys

How does this work when SSH thinks I am the git user with commands like:

git remote add origin git@gitserver:/srv/git/project.git

I don't understand how SSH keys for user can allow ssh authentication for user git.

The permissions for the repository on gitserver are for user git not user 'user`.

I am using a config file for the normal SSH access which does work, maybe that is the problem?

User alan
IdentityFile /home/alan/.ssh/my-workstation_alan-id_ed25519
IdentityFile /home/alan/.ssh/my-workstation_alan-id_rsa
IdentitiesOnly yes
Host gitserver
HostName GitserverIpAddress

This works for normal "non-git" access with:

$ ssh gitserver

---

Update:

In investigating the config file, a few more questions have arisen:

1. There is no git user or group on the user workstation. In this case no .ssh/config file and I presume the command "$ git push origin master" accesses the SSH system as the user issuing the command?
2. Do permissions in the traditional sense matter? The command $ git push origin master, I presume can access the repository on the Git server when the repository only allows access to user and group git?

Tests:

1. This first connection works, despite the initial error message

user@myworkstation~/files/git/Test $ ssh -I user-id_ed25519 user@gitserver

dlopen user-id_ed25519 failed: user-id_ed25519: cannot open shared object file: No such file or directory

Enter passphrase for key '/home/user/.ssh/user-id_ed25519':

Last login: Tue Jan 12 09:15:17 2021 from aa.bb.cc.dd

user@gitserver: $ exit

logout

Connection to aa.bb.cc.dd closed.

2. This second connection does not

user@myworkstation~/files/git/Test $ ssh -I user-id_ed25519 git@gitserver

dlopen user-id_ed25519 failed: user-id_ed25519: cannot open shared object file: No such file or directory

[email protected]: Permission denied (publickey).

user@myworkstation~/files/git/Test $

Answer 1

First, let's resolve one fundamental misconception: ssh keys are not specific to a user, neither from the perspective of the client nor the server. This is true regardless of what might be implied by the comment at the end of a public key, which often contains the username of the user that generated the key. The only thing that matters is if you have the private key that corresponds to the public keys accepted by the server (e.g. in the authorized_keys file).

By analogy, think of physical, real-world doors and keys. You can have a physical key (analogous to an ssh private key) and you can have multiple doors with locks that accept that key. You can even lend that physical key to a friend and they can unlock that door, though that is an even worse idea in the realm of computer security than in the real world.

Completing the analogy then:

• real-world, physical key == ssh private key (e.g. id_rsa or id_ed25519)
• real-world door == ssh server
• real-world door lock == authorized_keys file containing one or more public keys (e.g. contents of id_rsa.pub)

We can continue the analogy: you can duplicate your real-world key just like you can duplicate your private key, but that's not relevant to your question.

In your case, you have a git server gitserver. You can ssh to that server as the user user or alan using any ssh private key for which you have installed the corresponding public key into that remote users' ~/.ssh/authorized_keys file.

Returning to your actual problem now, there are a couple of possible sources of error:

1. The config file snippet you provided looks very odd and you may have something wrong in that file. Generally entries in ~/.ssh/config look something like this:

    Host remote
      HostName remote.example.com
      User alan
   

   While indentation is optional, most users have multiple entries for different hosts, each a separate block. You can also use wildecards to apply to multiple hosts, or even all hosts, as in:

    Host *
      IdentityFile /home/alan/.ssh/my-workstation_alan-id_rsa
   

   Note that the specification and parsing of config files occurs is a "first answer wins" model - that is, you need to put more generic wildcard host entries at the end of your file or things will get complicated and probably not work.

2. When you say 'this is not working', I don't think we yet have enough information. If you are trying to do something like this:

    ssh git@gitserver
   

   That won't likely work as you might intuitively expect (i.e. give you an interactive shell) simply because the git server software sets up the user git on gitserver with a different shell. Look in /etc/password for the shell of the user git - probably something like git-shell or gitaly. When you try to simply ssh gitserver, you are implicitly asking to get an interactive shell, and the common git server shells (e.g. git-shell) don't do that.

Suggest you look at your configuration, try a few things, and then update your question or post additional comments with more details. If needed, I'll revise my answer.