Git submodules and ssh access

Question

I have some trouble with a git repository that contains several submodules.

The super git repository was constructed with the commands

mkdir projectname
cd projectname
git init
git submodule add ssh://myusername@server/pathtorepos

When a different user ("otheruser") then clones the super repository everything seems to work out. But when it is time to get access to the submodule

git submodule init
git submodule update

git tries to clone the submodule using "myusername" instead of "otheruser".

How to solve this problem?

Answer 1

Don't use absolute URLs! In an open-source project we use a RELATIVE URL when adding the submodule, and that goes in the .gitmodules file. This will cause git to clone the submodule URL based on the URL of the parent project. Using a relative path neatly avoids specifying protocol (https, ssh) and username entirely.

For example, if the submodule my-schema that you want is available from your Git server as a peer repository, work in your repo's root directory to add that peer repo as a submodule like this:

git submodule add ../my-schema my/tests/schemas              

Then the .gitmodules file is created/extended with an entry like this:

[submodule "my/tests/schemas"]
    path = my/tests/schemas
    url = ../my-schema

This way, nobody has to edit the modules file.

p.s. after posting I realized that my answer is a dupe, here is the source you should use: Automatically access git submodules via ssh or https

Answer 2

Debugging

Usually, the problem with cloning (using ssh) is that git tries to use ssh for authentication to the remote and it fails. You can debug this process using which ssh and furthermore adding verbose mode using

GIT_SSH_COMMAND="ssh -v" git clone --recurse-submodules [URL]

or for windows set GIT_SSH_COMMAND=ssh -v and then running the clone command.

While it might be a correct answer to not to use absolute URLs for submodules or avoid adding users to these urls for this particular question; I (and probably many others) arrive here in search for solution to trickier problems with ssh access and I felt such debugging can help in many cases, as it did for me.

Example

I was using Windows CMD+WSL2. Running the ssh -v verbose output for git commands I got

...
debug1: Next authentication method: publickey
debug1: Offering public key: [--].ssh/id_rsa RSA SHA256:[--]
debug1: Server accepts key: [--].ssh/id_rsa RSA SHA256:[--]
debug1: read_passphrase: can't open /dev/tty: No such device or address  <-- !!!
debug1: Trying private key: [--].ssh/id_ecdsa
debug1: Trying private key: [--].ssh/id_ecdsa_sk
debug1: Trying private key: [--].ssh/id_ed25519
debug1: Trying private key: [--].ssh/id_ed25519_sk
debug1: Trying private key: [--].ssh/id_xmss
debug1: Trying private key: [--].ssh/id_dsa
debug1: No more authentication methods to try.
git@[--]: Permission denied (publickey).
fatal: Could not read from remote repository.

Which told me that the ssh cannot probably access the terminal to get the password for the rsa key. Although it worked for the main repository, it did not for the submodules. So after a while, I read somewhere that windows added its own OpenSSH version. The git for windows installation was using its own ssh that could not find the terminal device. I was able to fix submodule cloning via ssh for WSL2 + CMD using

set GIT_SSH_COMMAND="C:/WINDOWS/System32/OpenSSH/ssh"

Answer 3

My 2 cents:
I had a problem updating the Submodule repo from within the Parent with the same user who created the repo. I found it was caused by the passphrase on the SSH key. When the Parent - Child repositories are connected as submodules and persisted to Git, I tried to clone the project to a new location. Cloning the parent succeeded (when cloning with an SSH key, I entered passphrase for the key). However, the git submodule update command failed with Permission denied (publickey...), without asking for the passphrase. When I removed the passphrase, the update command ran successfully.

Answer 4

Do not include the username in the URL. git will prompt for the username and password when you clone/pull/etc

Answer 5

If possible, it's best to make sure that the .gitmodules file contains a URL for the repository that can be cloned by anyone, typically either a git:// or http:// URL. Then users that have SSH access themselves can change into the submodule after cloning and change the URL in remote.origin.url to point to an SSH URL with their username, e.g.:

 cd my-submodule
 git remote set-url origin otheruser@server:/pathtorepos

The other user should be able to do that even in the current situation. Update: Chris Johnsen points out below that it's also reasonable to use an SSH URL in .gitmodules if you omit the username and all the users of the repository will have SSH access - they'll need to add their username similarly to the above if it differs locally and remotely.

Note that the URLs in .gitmodules are only used when initializing the submodule. Initializing the submodule sets the config value submodule.<SUBMODULE-NAME>.url in the main project to whatever's committed in .gitmodules - this is the value that will be used on the first submodule update. Between initializing and updating the submodule, you can also change this URL that will be used for that first update with a command like:

git config submodule.my-submodule.url otheruser@server:/pathtorepos

Indeed, you may need to do this if the first update fails. Once the submodule has been updated for the first time, the URL you need to change is that defined for origin within the submodule - at that point it's only useful to set the submodule.my-submodule.url config value in the main project if you're likely to be deleting and re-updating the submodule.

Answer 6

Just for reference, the solution I ended up using is the following. It is actually possible for others to check out the existing repository.

When I need to check out the repository it can be done with the commands

git clone ssh://myusername@server.dk/path/to/superrepos
cd superrepos
git submodule init
git submodule update

For others to check out the super repository, the following set of commands is used. The only difference is the manual cloning of the other repository

git clone ssh://otheruser@server.dk/path/to/superrepos
cd superrepos
git clone ssh://otheruser@server.dk/path/to/other/repos
git submodule init
git submodule update

Note that after issuing the

git submodule init

command, git will tell you that the requested repository and the available is not identical. But this is not fatal and you can safely continue.

Answer 7

The other user has to alter the .git/config file to change the user name to his own username. That way, git uses the right user to connect to the server.

[submodule "path/to/module"]
    url = ssh://otheruser@server/pathtorepos