2017-12-06 2 views
1

Dies ist nur eine allgemeine Frage, wie git funktioniert. Ich konnte nichts in dem Git Handbuch zu diesem Thema finden, vielleicht schaue ich nicht an der richtigen Stelle.Warum git mit ssh git als Benutzernamen verwenden

Wenn Sie mit einem ssh-Link von einem Git-Server klonen, ist der verwendete Benutzername git, nicht der Benutzername des Schlüssels, den Sie verwenden möchten. Warum macht Git dies und wie kann Git sagen, welches Schlüsselpaar es verwenden soll, um die Verbindung zu authentifizieren?

+1

Normalerweise gibt es einen Dienst, der das Repository bedient. Dieser Dienst muss mit einem Benutzer ausgeführt werden, der nicht root ist. Es gibt eine Art Konvention, die besagt, dass der Benutzername mit dem Service identisch ist. Zum Beispiel ist es üblich zu sehen, Apache läuft mit Apache-Benutzer, ftp mit ftp, nginx mit nginx, etc. Also Leute verwenden git für diese auch. Sie könnten einen Benutzernamen TaylorSwift erstellen, aber nicht sehr leicht zu verstehen, wofür dieser Benutzer ist ... – geckos

+0

Es muss nicht "git" sein. Der Benutzername des Schlüsselpaars ist normalerweise der Benutzername, mit dem Sie sich auf dem lokalen Computer anmelden. Einige der Remote-Dienste werden von einem Benutzer mit dem Namen "Git" auf Github ausgeführt. Der öffentliche Schlüssel des lokalen Benutzers wird an "git" gesendet, damit der lokale Benutzer auf die Dienste mit dem Benutzernamen "git" zugreifen kann. Für andere Hosting-Dienste wie Gerrit registriert jeder Benutzer einen Benutzernamen, der normalerweise mit dem lokalen Benutzernamen identisch ist. – ElpieKay

Antwort

1

Wenn Sie eine SSH-Verbindung von einem Git-Server-Klon verwendet wird, ist der Benutzername verwendet es git, nicht der Benutzername des Schlüssels Sie versuchen, zu verwenden.

Korrekt. Der Grund dafür ist, dass der Dienst an ein Benutzerkonto gebunden ist und Sie auf den Server als diesen Benutzer zugreifen müssen, um den Dienst aufzurufen. Dies ist wirklich eine Eigenschaft von SSH und nicht von Git - Git verwendet SSH nur als Transportmittel. Außerdem weiß SSH - und damit Git - nichts über den Benutzer, der mit dem SSH-Schlüssel verbunden ist - nur, dass er für den Zugriff auf das Konto genehmigt wurde. Dies geschieht normalerweise über die Datei authorized_keys für den Git-Benutzer, und Tools wie Gerrit oder Gitolite verwalten diese Datei beim Hinzufügen und Entfernen von Benutzern. Die Datei authorized_keys ermöglicht das Angeben eines bestimmten Befehls, der bei der Authentifizierung ausgeführt werden soll. Diese Tools verwenden diese Funktion, um den Benutzer zu kommunizieren. Anschließend bestimmt die App die Berechtigungen von dort.

Warum macht Git dies und wie kann Git sagen, welches Schlüsselpaar es verwenden soll, um die Verbindung zu authentifizieren.

Hier ist ein bisschen ein Missverständnis. Einige davon sind nicht so sehr Git, sondern SSH. Und Werkzeuge wie Git verwenden SSH als Transport, weil es die harte Arbeit der Authentifizierung, Sicherung der Netzwerkaktivität und Werkzeuge wie ssh-agent zur Erleichterung der Authentifizierung getan hat. Warum erfinden Sie das Rad neu?

Das Schlüsselpaar ist tatsächlich eine von zwei Möglichkeiten bestimmt: Sie geben es in Ihrem ~/.ssh/config (das ist, was ich tue), oder Sie lassen ssh durch die verfügbaren Schlüssel gehen und es herausfinden. Letzteres kann zu Problemen führen, wenn der Administrator strenge Regeln eingerichtet hat, da ein nicht funktionierender Schlüssel als Authentifizierungsversuch gilt. Die meisten Leute haben nicht mehr als einen Schlüssel, also ist es im Allgemeinen kein Problem.

Sie können mithilfe ssh -v [email protected], oder je nachdem, welcher Server Sie gehen gegen geschieht einige dieser Verhandlung sehen:

OpenSSH_7.4p1, LibreSSL 2.5.0 
debug1: Reading configuration data /Users/jszakmeister/.ssh/config 
debug1: /Users/jszakmeister/.ssh/config line 286: Applying options for * 
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: Control socket "/tmp/[email protected]:22" does not exist 
debug1: Connecting to github.com [192.30.255.113] port 22. 
debug1: Connection established. 
debug1: identity file /Users/jszakmeister/.ssh/id_rsa type 1 
debug1: key_load_public: No such file or directory 
debug1: identity file /Users/jszakmeister/.ssh/id_rsa-cert type -1 
debug1: Enabling compatibility mode for protocol 2.0 
debug1: Local version string SSH-2.0-OpenSSH_7.4 
debug1: Remote protocol version 2.0, remote software version libssh_0.7.0 
debug1: no match: libssh_0.7.0 
debug1: Authenticating to github.com:22 as 'git' 
debug1: SSH2_MSG_KEXINIT sent 
debug1: SSH2_MSG_KEXINIT received 
debug1: kex: algorithm: [email protected] 
debug1: kex: host key algorithm: ssh-rsa 
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none 
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none 
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY 
debug1: Server host key: ssh-rsa SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 
debug1: Host 'github.com' is known and matches the RSA host key. 
debug1: Found key in /Users/jszakmeister/.ssh/known_hosts:25 
Warning: Permanently added the RSA host key for IP address '192.30.255.113' to the list of known hosts. 
debug1: rekey after 134217728 blocks 
debug1: SSH2_MSG_NEWKEYS sent 
debug1: expecting SSH2_MSG_NEWKEYS 
debug1: SSH2_MSG_NEWKEYS received 
debug1: rekey after 134217728 blocks 
debug1: SSH2_MSG_SERVICE_ACCEPT received 
debug1: Authentications that can continue: publickey 
debug1: Next authentication method: publickey 
debug1: Offering RSA public key: /Users/jszakmeister/.ssh/id_rsa 
debug1: Server accepts key: pkalg ssh-rsa blen 277 
debug1: Authentication succeeded (publickey). 
Authenticated to github.com ([192.30.255.113]:22). 
debug1: channel 0: new [client-session] 
debug1: Entering interactive session. 
debug1: pledge: network 
PTY allocation request failed on channel 0 
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 
Hi jszakmeister! You've successfully authenticated, but GitHub does not provide shell access. 
debug1: channel 0: free: client-session, nchannels 1 
Connection to github.com closed. 
Transferred: sent 2988, received 1868 bytes, in 0.2 seconds 
Bytes per second: sent 19242.2, received 12029.6 
debug1: Exit status 1 

Ich bin nicht sicher, dass ganz beantwortet Ihre Frage, aber ich hoffe, es hilft.

aktualisieren

SSH ist ein extrem leistungsfähiges Werkzeug, das auch viele Konfigurationsmöglichkeiten hat. Eine Sache, die Sie tun können, um das Leben ein wenig einfacher zu machen, ist, Ihre Konfiguration so einzurichten, dass sie den Benutzernamen und die Schlüsseldatei anwendet, die Sie verwenden möchten:

~ /.ssh/config

Host gh 
    Username git 
    Hostname github.com 
    IdentityFile ~/.ssh/id_github 

Man könnte so etwas wie die oben verwendet git clone gh:foo/bar.git zu ermöglichen, im Wesentlichen bedeutet git clone [email protected]:foo/bar.git und einen anderen SSH-Schlüssel zur Authentifizierung verwenden. Ich benutze diese Funktion immer und nicht nur für Git-bezogene Sachen.

+0

Danke, das hilft. Ich benutze Git seit Jahren und das ist nur eine kleine Eigenschaft, die mich immer verwirrt hat. –

+0

@MattG. Ich bin froh, dass es geholfen hat! Ich war definitiv verwirrt, als ich das erste Mal so etwas sah. Es ist eine saubere Lösung für ein Problem, aber der Benutzername ist verwirrend. Außerdem werde ich meine Antwort aktualisieren, um eine Beispielkonfiguration für ssh anzuzeigen, mit der Sie einen Hostnamen erstellen und den Benutzernamen für Sie übernehmen können. Zumindest müssen Sie es dann nicht ansehen. :-) – jszakmeister

0

Vergessen Sie nicht, dass Sie tatsächlich nicht in der Lage wären, einen interaktiv Secure Shell auf den Remote-Git-Repositories zu öffnen Hosting-Server:

  1. Sie haben kein Geschäft auf diesem Server jeden gewünschten Befehl ausführt
  2. Ihr Konto wird nie erstellt (wegen 1.)
  3. Die einzigen Befehle, die Sie interessieren sollten, sind Git-Befehle (upload-pack, receive-pack, für die Implementierung der Git-Klon/pull/push Sie tun.)

Aus all diesen Gründen ist das einzige Konto, für das Sie eine Remote-Shell anfordern müssen, ein Administratorkonto, das diese Remote-Repos verwaltet, die normalerweise 'git' heißen.

Einige dieser Server die ssh-Funktion ‚gezwungen Befehl‘ Namen verwenden würde (I presented it here for Gitolite, aber es gilt auch zu Gitlab)
Das heißt, es Ihren Account-Namen kennt, weil es als Parameter einer Zwangs geschrieben Befehl, der Ihrem öffentlichen Schlüssel in ~git/.ssh/authorized_keys zugeordnet ist, der alle öffentlichen Schlüssel verfolgt, die zum Öffnen einer (nicht interaktiven) Shell berechtigt sind.
So weiß der Git-Hosting-Dienst, welche Konten eine Git-Anfrage stellen.

Verwandte Themen