Can't Clone on Windows But Can Clone on Linux from Gitlab Server

Can't clone on windows but can clone on linux from Gitlab server

Note: I just upgrade to Git 2.14.0 for Windows... and none of the ssh url are working:

> git ls-remote
GitLab: Disallowed command
fatal: Could not read from remote repository.

(with origin being an ssh url)

Another side effect: git-for-windows/git issue 1258

fatal: protocol error: bad line length character: Not

It looks as if BitBucket looks at argv[0] (typically git-upload-pack, with the regression git) to determine whether it is a permitted command.

So I think it is by design that git is rejected while git-upload-pack is not.

Same kind on error on GitLab: gitlab-ce issue 36028.

The pending merge request explicitly restore git-xxx when it detects a git xxx command.

See gitlab_shell.rb#parse_cmd(args)

  def parse_cmd(args)
    # Handle Git for Windows 2.14 using "git upload-pack" instead of git-upload-pack
    if args.length == 3 && args.first == 'git'
      @command = "git-#{args[1]}"
      args = [@command, args.last]
    else
      @command = args.first
    end

At the Git for Windows side, a fix is in progress: see commit 0f33428

Revert "git_connect: prefer Git's builtins over dashed form"

It would appear that this change (which was intended to fix tests
interacting with local repositories when git-upload-pack was not in the
PATH) regresses on SSH access.

A Git for Windows 2.14.0(2) is in the work and was just released (2017-08-07T11:05:34Z UTC) 30 minutes ago at the time of this edit.

---

Original answer

If key1 is the same as your /path/to/.ssh/key and does identify John Doe, that should mean John Doe does not have access to that repo (as in here).

Check that key2 is associated with a different user.

If both keys reference the same user, then it is more a local configuration issue (as in this answer).
Check also that your TortoiseGit does use the same key as in your test:

set "GIT_COMMAND_SSH=ssh -v"
# launch TortoiseGit from that CMD session

You will then see what TortoiseGit is using when cloning the repo with an ssh url. You might need to define an .ssh/config file.

Gitlab can't clone on server, but can clone on client

The problem is not git but your permssions on Ubuntu

Update: I was able to clone a repo but via HTTP

There you go. The gitlab server is supposed to be accessed via HTTP(S), because usually you don't clone from a repository that is located on the same computer.

To prevent other users or apps from accessing/manipulating data in the repositories, only the gitlab server has access to its files.

Although this is not recommended (because it is against linux' permission philosophy where each server has got its own user account) you can still give yourself permissions.

Variant 1 (less invasive)
Either add yourself to the group under which the gitlab server is running

sudo usermod -a -G gitlab paul

and ensure the owner group does at least have reading permissions on the directory

sudo chown g+r /var/www/path/to/the/repo

and on the files (update)

sudo chown -R g+r /var/www/path/to/the/repo

Variant 2 (dirty, simple hack)

If you can ensure nobody else with an account on your computer wants to access (private) repositories on gitlab, you can give everyone read permissions:

sudo chown o+r /var/www/path/to/repo

The operating system will then allow you to access the folder and git will be able to clone from the local path.

However it's a good practice to use systems as they were thought to use. If you clone using the local path gitlab won't notice this and, for example, will not adjust the statistics or run web hooks.

Why can I clone from one machine, but not from another?

The Solution

In conclusion, it was indeed because I did not have my .ssh public key added to the user account in gitlab. The steps to fix this were;

1. ssh onto my linux box as the user I want to clone as. I have created a user specially for this purpose.
2. ssh-keygen -t rsa -C "newuser@my.domain.com" - (The -C part is a comment that helps me work out whose key this is if I ever forget.)
3. Copy the contents of the public key (whilst still logged into linux box as my new user) with cat ~/.ssh/id_rsa.pub
4. Log into gitlab (as a user who has permission to access the project that you want to clone) and add this ssh key to the account, by pasting the public key that you just copied in step 4.

Now I can clone using my original command;

git clone gitlab_user@my.gitlab.domain:my_namespace/my_repo.git my_repo

What I Learned

I will always initially connect to my gitlab server as user gitlab_user. But upon arrival, gitlab will identify which user account I am claiming to be by matching my public key with one stored against one of the accounts it has in its database. That's why you can't attach the same .ssh key to more than one gitlab account - gitlab wouldn't know who you were when you connected.

However, you can put more than one (different) key on a single account. For example, I need to be able to access the repo from home and from the office, but be identified as the same gitlab user each time. I do this by creating as .ssh key at home and adding it to my gitlab account, and doing the same at work. Two different keys, identifying me as the same gitlab user.

Gitlab - unable to clone via SSH, but SSH works itself

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.

Why can't gitlab-runner clone my project? (Incorrect hostname, failed to connect)

As described here, the solution is to replace the entry host: localhost in the Gitlab config file /home/git/gitlab/config/gitlab.yml with the IP address of the host.

Before replacing:

  gitlab:
    ## Web server settings (note: host is the FQDN, do not include http://)
    host: localhost

After replacing:

  gitlab:
    ## Web server settings (note: host is the FQDN, do not include http://)
    host: 10.0.1.2

Cannot clone remote git repo via ssh

Hi username! You've successfully authenticated, but GITEE.COM does not provide shell access.

Your keydoes work for basic authentication, but you are still unable to clone username/demo-repo.git (assuming that "username" is the same one as in the Hi username! message)

As I mentioned before, you might need to create a ed25519 key instead:

cd %USERPROFILE%\.ssh
ssh-keygen -t ed25519 -C  "xxxxx@xxxxx.com"  -P "" -f gitee

And a %USERPROFILE%\.ssh\config with

Host gitee
  Hostname gitee.com
  User git
  Identityfile ~/.ssh/gitee

Finally: git clone gitee:username/demo-repo.git (no git@gitee.com, just gitee)

git clone: Authentication failed for URL

The culprit was russian account password.

Accidentally set up it (wrong keyboard layout).
Everything was working, so didnt bother changing it.

Out of despair changed it now and it worked.

If someone looked up this thread and its not a solution for you - check out comments under the question and steps i described in question, they might be useful to you.

---

Related Topics