5

I followed this tutorial to set up a git repository on an EC2 instance. http://git-scm.com/book/ch4-4.html. Basically, I add a new git user and include my public key in authorized_keys. After setting up the git user, I just initialize a new repo by git init --bare.

However, I've noticed that I can clone it easily without needing my private key. Is there a way to force it to only be available via SSH so authorized_keys is followed? I'm guessing it's using the default of git which is port 9418 which doesn't seem to support authentication.

UPDATE

Ok, I've tried it on a fresh box without any keys, and I was unable to login or clone my repo. I realized ssh-add -D wasn't working for me for some reason. I'm selecting the most helpful answer, thanks.

  • 1
    Git has only 2 major transfer protocols: ssh & http(s). As far as I know, theres no such thing as a "git protocol". How does your git clone command look like? Cut it be that your ssh key has no passphrase and is in authorized_key on remote site and you misinterpret this as lack of authentication? – Henrik May 26 '15 at 14:56
  • Nothing in the page you linked to starts anything listening on port 9814. I really am not sure what you are talking about here. – Zoredache May 26 '15 at 18:07
  • I've already removed the key from my ssh agent and have tried removing the public key on authorized_keys, and confirmed I can still clone from the repo. I clone it using git clone git@host.com I am not sure if it is called git protocol, but I was talking about this: kernel.org/pub/software/scm/git/docs/git-daemon.html which is a daemon running on TCP 9418 – gerky May 27 '15 at 16:08
  • Have you tried blocking the port in the firewall? This would prevent anyone from being able to connect over it. – Nathan Jun 2 '15 at 16:54
  • 2
    There is a git protocol. To stop it, you need to stop running git-daemon. The confusion from @Henrik and others may be due to major git providers only exposing https and ssh due to security. – Belmin Fernandez Jun 2 '15 at 17:19
7
+50

Port 9814 is where git-daemon runs (e.g clone, git clone git://git.example.com/repo). This is meant for an internal git repository. Read the documentation for more details.

You have 2 other options for setting up a remote git server:

  • SSH server: git clone ssh://git.example.com/git/repo
  • HTTP server git clone https://git.example.com/git/repo

SSH is a lot easier to setup. You just need to make sure all contributors have access to the SSH account. This is normally done via SSH keys---each developer adds their public key to a git SSH account.

Just remember:

  • Specify the protocol in your command (i.e., ssh, git, http or https).
  • Make sure you have firewall setup correctly:
    • Usually port 22 for ssh
    • Usually port 443 for https
    • The other two should be avoided but, for ref, port 9814 for gitand port 80 for http
  • Yes, based on the above link, I've gone with the ssh server. My problem is that it is still available via port 9814 and not enforced using authorized_keys. – gerky Jun 2 '15 at 15:59
  • You could disable git-daemon. It will never enforce SSH keys. You'll have to use SSH. E.g., git clone git@github.com:thias/puppet-fooacl.git – Belmin Fernandez Jun 2 '15 at 16:37
  • @mumble Why aren't you using a firewall anyway, and only allowing ports you explicitly need? – EEAA Jun 2 '15 at 21:19
  • @EEAA I've tried blocking the port via the SG. Apparently, it's using ssh already but weird that it doesn't require my private key. – gerky Jun 3 '15 at 14:58
  • So you do not have git-daemon running but you still are able to do git clone git://<repo URL>? is that what you're saying is the problem now? – Belmin Fernandez Jun 3 '15 at 15:53
1

You seem to be under the assumption that git-daemon is responsible. Have you confirmed that git-daemon is, in fact, running on the system? Check the process list as well as the open ports list:

$ ps auxwww | grep git-daemon
$ sudo netstat -ptuna | grep 9814

If git-daemon is not running and there's nothing listening on port 9814, it's possible that there's something else amiss -- perhaps the new git user you've added does not have a password set or the SSH configuration is using Kerberos and you have an existing valid service ticket.

HTTP and SSH are only two of the half dozen or so protocols that git supports. I believe that git only ever uses SSH with URLs of the form user@host, so I'm pretty certain it's an authentication issue with your git user.

When you clone the repo, watch the auth log on your system (typically /var/log/auth.log or /var/log/secure). If you see SSH logins for the git user during the clone operation, then it's almost certainly using SSH and not git-daemon.

  • Ok, just checked and git-daemon wasn't running after all and there's nothing listening on 9814. I also checked /var/log/auth.log and was able to see the git user login via sshd (New session 68 of user git). Could you elaborate on "perhaps the new git user you've added does not have a password set or the SSH configuration is using Kerberos and you have an existing valid service ticket"? – gerky Jun 3 '15 at 15:00
  • I doubt you have Kerberos setup with an EC2 instance, so let's focus on the first part. It is possible to configure a user with an empty password. In systems with shadow passwords, this will show up in /etc/shadow with nothing in the second field: $ sudo getent shadow test test::16594:0:99999:7::: Note the lack of any encrypted password between the two colons. The SSH daemon is often configured to disallow logins for users with empty passwords, but it all depends on the value of the PermitEmptyPasswords directive in your configuration. Have a look at /etc/ssh/sshd_config. – diz Jun 8 '15 at 13:27
  • Well, that wasn't formatted as I'd hoped. Let's take a quicker path to diagnosing this. The SSH daemon will record the authentication method used when logins are accepted. If public key authentication is used, it will be recorded to /var/log/auth.log with "Accepted publickey for <user>". Might check to see what authentication method is being accepted for your git user. – diz Jun 8 '15 at 13:35

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.