What I'm trying to achieve is to clone into a repo from my local gitlab instance using SSH, what I have done is:
- I have created a user with an SSH key in gitlab
- In the project I have added user as a maintainer, he also has an Admin rights
- I'm cloning using myusername@address:git/name.git which ends up with msg:
fatal: 'git/name.git' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
- When I simply connect using SSH it seems to work perfectly fine
ssh username@address
username@address's password:
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-118-generic x86_64)
I have tried to check gitlab's auth.log but it's empty, and btw I'm trying to clone from a windows machine. I'm not using standard git account here, I want users to have to use their own account to clone. Cloning via http works fine. Can you guys please advise what am I doing wrong here or how should I troubleshoot this?
CodePudding user response：
Item 3 here is almost certainly where you are going wrong:
I'm cloning using myusername@address:git/name.git ...
The main reason for setting up a fancy system like GitLab is so that you don't log in as yourself. Instead, you log in as git@hostname: in fact, everyone who uses the fancy setup, which lets multiple users collaborate on shared repositories, logs in this way. The underlying OS then handles the repositories, whose permissions are given only to the git user (or other user of your choice: in this case, replace git@ with user@ everywhere). The fancy system uses ssh's authentication to figure out who's coming in as git@host, looks in its own permissions tables to see who has which permissions on which repositories, and then grants or denies permission itself, without the OS getting involved at all.
Hence, none of the repositories on the server are in anyone's user workspace. They are in the pseudo-user's home directory (~git), or somewhere else as dictated by the fancy software. Logging in on the server as yourself, you won't be able to access the repositories, as they're owned by the pseudo-user, so the OS itself will deny permission to you (at least for writing: you might be able to read them, and of course on a Linux-like system, if you have superuser or sudo privileges you can use that to get to the repositories for special maintenance operations, for instance).
If everyone in your organization has direct ssh access, you can use the much simpler and less-fancy basic group-shared Linux modes for repositories. Of course this also lacks all the superstructure for doing code reviews, providing protected branches, and so on. You don't need GitLab or anything like it at all. This makes it much more pleasant to use, but is less appropriate (or not at all appropriate) for typical corporate settings—which is why things like GitLab exist in the first place.
Note that when you go in through a web server, the web server sits between you and the OS. So you have probably set up your web server as directed in your GitLab documentation, and the web server is using GitLab as the appropriate pseudo-user. That would then explain why you cannot get to the repositories as yourself. You must set up the pseudo-user (as described in your GitLab documentation) and then log in as git (or whatever pseudo-user you designate), using an SSH key-pair where the public key has been loaded into the pseudo-user's setup so that it will know that it's you coming knocking at the pseudo-user's login.