When I first started working with Git, I was immediately generated keys on GitHub. Time passed, and I absolutely do not understand why they are needed. In BitBucket, I have no keys, but I can create a repository, clone it and successfully push without SSH. Or do pull requests.

Everywhere they explain this from the position of working with the server, but even here I don’t feel the difference. I do push on a lokalka. Everything is pushing on BitBucket. I pull on my instance in DO. What's wrong?

1 answer 1

Let's take a look at ProGit :

Git can work with four network protocols for data transfer: local, SSH, "own" Git and HTTP [S].

The basic protocol is the Local Protocol, in which using a remote repository is simply a directory on the disk. Not suitable for remote access via the network, except for special cases using network file systems (NFS, CIFS, etc.)

Probably the most commonly used transport protocol is SSH. The reason is that SSH access is usually already configured in most environments. In addition, SSH is the only network protocol that provides both read and write access. The other two network protocols (HTTP [S] and Git) in most cases give access only to read, so even if they are available to you, you still need SSH to write. In addition, SSH is a protocol with authentication and encryption of traffic out of the box. The disadvantage of SSH is that, using it, you cannot provide anonymous access to the repository.

Another option is "your" Git-protocol. Git comes with a special daemon that listens on port 9418 and provides a service similar to the ssh protocol, but without authentication at all. To use the Git protocol for the repository, you must create the git-daemon-export-ok file, otherwise the daemon will not work with this repository, but remember that there are no security tools in the protocol. Accordingly, any repository in Git can be either available for cloning to everyone, or not accessible to anyone. As a result, usually you cannot send changes via this protocol. Technically, you can open access to the record, but due to the lack of authorization in this case, anyone who knows the URL of your project will be able to change it. In short, this is a rarely used feature.

And the last option is HTTP [S]. The beauty of the HTTP and HTTPS protocols is in their simplicity. In fact, all that needs to be done is to place the bare repository inside the directory with HTTP documents, install the post-update interceptor and that's it. The downside of using the HTTP protocol is its relatively low efficiency for the client. Usually, cloning or retrieving changes from the repository using HTTP is much longer, and the amount of data and the load on the network is much larger than that of any other available network protocol.

Total: access to a remote repository via SSH - the most common option for setting up remote access, fast, convenient and secure. Having configured authorization in SSH by keys, you will be relieved of the need to enter passwords for access to the repository, while maintaining an acceptable level of security.

The author, are you sure that you are "pushing everything" not using ssh now?

  • on http, I also do not enter passwords - it was saved once and everything, and did not understand why SSH if everything works fine via https - godblessstrawberry
  • Can you write (push) to the repository via HTTPS? - AntonioK
  • Yes, of course, git push works fine, the first time a terminal asks for a username password and that's it - godblessstrawberry