(EDIT) This problem was happening also from my laptop using root and my user, which could get the greeting when trying to ssh with git user. Then tried the ansible playbook and it raised errors for the repo too. Tried another one and that clones flawlessly. The problem, then, doesn't seem to be with git, docker or ssh, but with the gitlab configuration.

On a Dockerfile I am trying to clone private repositories hosted on a company server running gitlab and setup with a non standard ssh port.

This is what I expected to run (alongside with some params in ssh config file)

RUN git clone git@companyname.ddns.net:GroupName/repo_name.git

Things I've checked already:

  • The repo has a deploy key and it is active.
  • Automating with Ansible instead of docker, it can connect and clone repos.
  • The key is named id_rsa and it is inside ~/.ssh/
  • Tried with ssh-agent and seems ok (though I specify the file in the config and shouldn't need it)

    Identity added: /opt/.ssh/id_rsa (/opt/.ssh/id_rsa) 
  • The ~/.ssh/config has the following:

    Host *
      StrictHostKeyChecking no
      PubkeyAcceptedKeyTypes +ssh-rsa
      PasswordAuthentication no
      User git
      ForwardAgent yes
      Identityfile /opt/.ssh/id_rsa # /opt is the home of the user RUNning the command in docker
      port 22022

RUNning this from the container:

ssh -vT -i /opt/.ssh/id_rsa git@companyname.ddns.net:GroupName/repo_name.git

Gets the result

Welcome to GitLab, Anonymous!

But the git clone command gets:

Cloning into 'repo_name'...
GitLab: The project you were looking for could not be found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights 
and the repository exists.
The command '/bin/sh -c git clone git@companyname.ddns.net:GroupName/repo_name.git;' returned a non-zero code: 128

Where is ~/.ssh/config ? Docker builds are done as root so that config would need to be in /root/.ssh/config

  • It is in /opt/.ssh/config . /opt being the home of the user I expect to run the git clone, after USER user_name. Ownership is explicitly changed and so are permissions, set to 400 Oct 4 '17 at 17:16
  • Hoping this was the problem, added the config file to both /opt/.ssh and /root/.ssh. The problem remains the same, sadly. Oct 5 '17 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.