1

I have an Ubuntu 12.04 server inside my office network that is being used to host our git repos. The server is running Gitlab 7.1.1, and has SSH on a non-standard port.

It works perfectly for everyone inside and outside of the office network with one exception. The exception is a managed server with a hosting company, so I only have limited access to it.

When I try to clone the repo on the non-standard port, it times out. I assume this is because the outgoing port is blocked by the hosting company. To solve that, I setup port forwarding on my office router to forward incoming traffic on port 22, to my non-standard port on the git server. I tested by cloning from a Digial Ocean VPS without specifying the port, and it worked fine.

But the problematic server now gives the following error:

Access denied.
fatal: The remote end hung up unexpectedly

The git server is registering an SSH connection being made, and accepting the public key, as shown in /var/log/auth.log:

Jan 20 15:09:07 gitlab sshd[3043]: Accepted publickey for git from 10.0.1.254 port 60771 ssh2
Jan 20 15:09:07 gitlab sshd[3043]: pam_unix(sshd:session): session opened for user git by (uid=0)
Jan 20 15:09:09 gitlab sshd[3162]: Received disconnect from 10.0.1.254: 11: disconnected by user
Jan 20 15:09:09 gitlab sshd[3043]: pam_unix(sshd:session): session closed for user git

That looks no different to any other auth request in the log, so I have no idea why the clone is failing?

I setup a test repo on Github, and the problematic server clones fine over SSH. It just has a problem with repos from my office server over SSH for some reason.

It's also worth noting that the problematic server can clone over HTTP with a username and password fine, it's only over SSH that is a problem.

Any ideas what the issue is here?

PS, I'm more a coder than server admin, I am getting involved in this to try improve my company's deployment process, so much of this is new to me

4
  • Could it be a permissions issue on the remote server?
    – NickW
    Jan 20, 2015 at 14:06
  • I don't think so. I have added the public key to the git server exactly the same as any other server I can successfully clone from.
    – shauno
    Jan 20, 2015 at 14:11
  • I would definitely speak with the company hosting your managed server. They may have an application-aware firewall in place that is killing the session.
    – Hyppy
    Jan 20, 2015 at 14:12
  • I tried already, the first line support isn't very helpful. The fact I am able to clone a Github repo makes me think there is something specific with my setup that's creating the issue too.
    – shauno
    Jan 20, 2015 at 14:23

1 Answer 1

1

I have resolved this.

The problem was the public key for the problematic server had already been added as a "deploy key" to Gitlab for earlier unrelated testing. It was then deleted as a deploy key, but for some reason the key persisted in the Gitlab DB. Gitlab then let me re-add the same key to a test user without complaining that it already existed elsewhere in the DB. But when trying to authenticate with that key, Gitlab would look up the key, and get the first "orphaned" key, so it would only give anonymous access which obviously wouldn't allow the clone.

To solve the issue, I found the orphaned key id, and removed it with the git-shell:

./bin/gitlab-keys rm-key key-21

Where 21 was the ID of the orphaned key.

Everything is now working as expected.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .