When i try to clone with ssh eg: [email protected]:service/test.git i get a request password for user [email protected] yet when i try the same thing with the http git http://test.company.com:service/test.git i get asked shh certificate userName,

why is that? and how can i make ssh request my actual user rather than [email protected]

I have tried configuring using git config --global commands to setup my username and password but still no avail.

CodePudding user response：

When using gitlab through ssh, you authenticate using a specific ssh key.

• on the server side : you need to register your public key (using gitlab's web interface)
• on your machine: you can set it in your .ssh/config file :

Host test.company.com
    IdentityFile ~/.ssh/company-key

CodePudding user response：

TL;DR

• When using ssh with Git, configure your ssh subsystem (only, usually). You may need to use Git-level configuration (git config --global) to select a particular ssh implementation, if your computer has more than one. The "user" will always be git; you'll need to use some non-Git system (e.g., a web page) to configure the server you're using.

• When using https with Git, configure Git to use your desired credential helper(s) using git config --global, then configure the particular credential helper(s) themselves using whatever means they use. You'll need both a user name and a password, token, or whatever.

Long

Secure Shell (ssh) and Hypertext Transfer Protocol Secure (https) are two entirely different protocols. They're generally controlled by entirely different configurations, and used with entirely different programs.

As LeGEC answered, ssh generally uses a per-host configuration entry, found in a file named config in a directory (folder) named .ssh in your home directory, to set options for connecting to that specific host. Here, you can list a user name and/or specific key-pair. The protocol itself uses public and private key-pairs to handle authentication, and works as follows:

1. A public/private key-pair provides means for encrypting and decrypting message texts. Someone who has the public key portion can encrypt text; someone who has the private key can decrypt such texts; but someone with the public key only cannot decrypt text that they have themselves encrypted. This math trick relies on "one way" hash functions or products of large primes or other things that may or may not survive a quantum-computing future (see also P vs NP problem and this question).

2. Your computer sends an outgoing request to the (or any) ssh service port on the target machine, over an IPv4 or IPv6 network.. When the server responds, it sends a "fingerprint" for that server and a lot of other information about what kind of encryption protocols it supports. Your host then checks this "fingerprint" to make sure it has reached the correct server.

   It is common today to use a "trust on first use" method. That is, if we've never contacted some particular host server (GitLab, GitHub, Bitbucket, whatever) before and don't know the correct fingerprint, we just take whatever fingerprint they send, perhaps showing it to the user and asking if it looks OK to the user, and then save that away. Later, on a subsequent connection to what's ostensibly the same server, ssh will make sure that it is the same fingerprint as last time. If the wrong fingerprint shows up, your ssh software will reject the attempt to connect, assuming that some Bad Guy has intercepted your attempt to communicate with the real server.

3. Assuming all goes well here, your ssh implementation and theirs now negotiate. Your computer asks to authenticate as a particular user name and, generally, provides the public key part of a public/private key-pair. The system generally assumes that you have somehow provided this same public key to that host previously (see note below). However, since anyone could have spied on your public key, it's now their job to verify that you actually possess the private key as well.

4. To test whether you have the private key, the server chooses some random data and encrypts it with the public key you sent. They then send this encrypted data to you. Using your private key, you decrypt the random data and send it back to the server. If you send them the correct decryption result, they now believe that you hold both halves of this particular key-pair. In other words, you seem to have the right to claim to be the user you are claiming to be.

Git hosting servers—GitLab included—set up this process so that when you log in, you usually are forced to present them with the literal string constant git as the user name. They therefore ignore the user you claim to be in your incoming request at this point. Instead, they look up the public key that you sent in a big table. Since you already stored that public key in their system (when you registered it as "this is a public key I will use in the future", however you went about doing that), they now believe that you are the person who registered that particular public key.

This whole process relies on the idea that no two different users ever have the same public key (which is true in practice, as users are told not to share their key-pairs with other users). Thus, "who you are" is determined solely by the key-pair that gains access. No other information is required, but you must attempt to "log in" as the user git when using ssh. You must then supply a key-pair that "works": one where the public key is already registered at the server, and for which you possess the corresponding private key.

HTTPS, by contrast, has a completely different trust model. Instead of a simple "user name and key-pair" system, this uses what used to be called a "secure socket layer" (SSL) and is now called Transport Layer Security or TLS.

TLS is far more complicated than ssh. See the Wikipedia page for background. The precise details of TLS 1.3 (which most systems now require) or 1.2 are beyond the scope of this answer (and I haven't delved into most of it myself), but as you have seen, you must generally provide a user name and password-or-token. Unlike the simple ssh case, the user name here is not ignored. You must provide the correct user name in this transaction.

Git does not "do" authentication

The most interesting wrinkle here, in my opinion, is that Git does not actually do any of this authentication. Instead, Git relies on other software, as follows:

• To use ssh and ssh authentication, Git simply runs ssh. The secure shell provides a streaming data facility, so that once the ssh connection is established, Git can send and receive data. The ssh program provides all the necessary encryption and decryption, authorization, and security. This is a clean and simple model and as long as ssh itself is secure, so is the connection.

• To use https, Git generally relies on a system-provided "libcurl" library or equivalent. Libcurl is associated with the cURL program found on modern computers. Since the interface itself is complicated, and Git itself is not encryption software, Git relies on credential helpers to obtain the user name and password-or-token portions of the transfer setup.

This is the reason for the two bullet points in the "TL;DR" section. Either Git is running ssh and ssh is doing the authentication, or Git is using libcurl and needs authentication information to feed to libcurl.