Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can I "disable" git-clone over http?

I'm using git to manage a tiny project. I've been performing all of my transactions (clone, push, pull, etc) through SSH, but recently ran git-update-server-info because I wanted to experiment with running git-clone over http. It worked great. Cool. Now I realize though that anyone can clone my repository over http without any credentials. I'm vaguely aware of setting up http authentication through gitosis, but that's really not what I want. I'd prefer to just disable http cloning entirely.

Is there a way I can tell git to only allow transactions over ssh? Or can I undo what I did when I ran git-update-server-info to enable cloning over http in the first place?

like image 762
George Mandis Avatar asked Aug 28 '09 18:08

George Mandis


People also ask

What is the difference between clone with SSH and clone with HTTP?

The difference is in the protocol used, as you probably guessed. Assuming you don't much care about the technical details between HTTPS and ssh, ssh has the advantage that you can use public key authentication, while you must use a username and password with HTTPS.

Is git clone necessary?

Show activity on this post. After the first git clone of a repository you don't need to re-clone it. A simple git fetch will due. You can have a loop that performs git fetch for each repository.

How do I restrict a github clone?

You can't stop people cloning repos they have access to, that wouldn't make sense! So, do you want to allow access to the repository when they login from workplace, but not their own computers. Can using a dedicated account for work do what you want?

Is git over HTTP?

Git can communicate over HTTP using two different modes.


2 Answers

For git repository to be available via HTTP transport, it needs to be "exported" by (any) web server. If your repository (to be more exact its .git directory) is visible from outside in a web browser, then it can be cloned or fetched anonymously via HTTP protocol. git update-server-info is used to generate extra auxiliary helper information (.git/objects/info/packs and .git/info/refs) for clone (or fetch) to know what is available.

So what you need to do is to either remove those two files (.git/objects/info/packs and .git/info/refs), or just make it so your repository is not available via web, perhaps by changing permissions in such way that user which web server runs as (usually 'nobody' or 'www', or 'apache') doesn't have access to .git repository. Or configure web server so that it doesn't export (make visible) your repository.

The HTTP protocol is (currently) so called "dumb" protocol, meaning that it serves files as is, and access control is done by a [dumb] server, in this instance by web server you use (or by filesystem).

I guess that your repository is not exported by web server, so you don't have anything to worry about: your repository is not available via HTTP.

Note that it is quote usual for Git repositories to have anonymous unauthenticated read-only access, and require authentication only for writing to repository i.e. pushing (at least for open-source projects)

like image 163
Jakub Narębski Avatar answered Sep 28 '22 03:09

Jakub Narębski


Is there a way I can tell git to only allow transactions over ssh?

6 to 8 years later, Git 2.12 (Q1 2017) will propose a configuration to allow or disable a protocol used by Git.

 git config protocol.http.allow never
 git config protocol.https.allow never
 git config protocol.git.allow never
 git config protocol.file.allow never

 git config protocol.ssh.allow always

See commit abcbdc0 (14 Dec 2016) by Jeff King (peff).
See commit a768a02, commit aeae4db, commit f1762d7, commit f962ddf, commit 85e4205 (14 Dec 2016) by Brandon Williams (mbrandonw).
(Merged by Junio C Hamano -- gitster -- in commit 9d540e9, 27 Dec 2016)

This allows for a finer-grained control of what protocols are allowed for transports during clone/fetch/push have been enabled via a new configuration mechanism.

git config now includes:

protocol.allow

If set, provide a user defined default policy for all protocols which don't explicitly have a policy (protocol.<name>.allow).
By default, if unset,

  • known-safe protocols (http, https, git, ssh, file) have a default policy of always,
  • known-dangerous protocols (ext) have a default policy of never, and
  • all other protocols have a default policy of user.

Supported policies:

  • always - protocol is always able to be used.
  • never - protocol is never able to be used.
  • user - protocol is only able to be used when GIT_PROTOCOL_FROM_USER is either unset or has a value of 1.
    This policy should be used when you want a protocol to be directly usable by the user but don't want it used by commands which execute clone/fetch/push commands without user input, e.g. recursive submodule initialization.
like image 38
VonC Avatar answered Sep 28 '22 03:09

VonC