it-swarm.com.de

GitLab benötigt das git @ localhost-Passwort, um ein Repo zu pushen

Ich versuche GitLab auf meinem Server zum Laufen zu bringen. Ich habe die Installationsanweisungen auf der Gitlab-Github-Seite befolgt und alles lief gut.

Das Problem ist, wenn ich ein Repo erstelle und versuche es

Sudo git Push -u Origin master

Ich werde nach "git @ localhost's password:" gefragt.

Der git-Benutzer hat kein Passwort, dies ist also ein Problem.

Andere Leute, die mit diesem Problem konfrontiert waren, schlugen vor, dass "AllowedUsers" in meinem sshd-conf git hinzugefügt werden sollte, aber ich habe dort kein "AllowedUsers" -Feld, so dass dies kein Problem zu sein scheint.

Ich bin immer noch ziemlich neu bei ssh, also glaube ich, dass es sich um eine Art ssh-Schlüsselproblem handelt, obwohl ich versucht habe, alle relevanten ssh-Schlüssel zu /home/git/.ssh/authorized_keys hinzuzufügen und festgestellt habe, dass die Datei keine Zeilenumbrüche enthält .

Nur zur Information, meine Installation besteht den Test vollständig, der im gitlab-Wiki enthalten ist:

Sudo -u gitlab bundle exec rake gitlab:app:status Rails_ENV=production

Anregungen sehr geschätzt!

BEARBEITEN

So kam ich endlich dazu, indem ich mich von einem anderen Rechner zu einem Repo verpflichte. Wie es war, wurde ich in dieselbe Maschine gehackt, auf der Gitlab lief. Sobald ich versuchte, mich von einem anderen Rechner als dem Host zu begehen, funktionierte es hervorragend. Das kann für manche Leute eine Lösung sein (für uns, da wir auf separaten Rechnern als unseren Servern entwickeln). 

Dies ist immer noch ein offenes Problem für alle, die versuchen, auf demselben Rechner zu hosten und zu entwickeln, der dies bereits getan hat. 

16
DevinR

TL; DR

Die Schlüssel werden sowohl auf der Gitlab-DB- als auch auf der Gitolit-Seite gespeichert. Sie sollten den im Werk erstellten Ordner gitolite-admin.git verwenden. Verwenden Sie nicht die Sicherung! Schlüsselbefehl. (Aktualisieren Sie die bereits in der Gitlab-Datenbank gespeicherten Schlüssel in gitolite).

Sudo -u gitlab -H bundle exec rake gitlab:gitolite:update_keys Rails_ENV=production

Wahrscheinlich liegt es daran, dass die Gitolit-Schlüssel nicht ordnungsgemäß gespeichert werden. Diese Tasten (zum Anmelden) werden von Gitlab und Gitolit tatsächlich getrennt aufbewahrt. Für Pull/Push werden die Tasten tatsächlich verwendet in gitolite gespeichert. (git/repositories/gitolite-admin.git/index, git/.gitolite/keydir, git/.ssh/authorised_keys)

gitlab sollte normalerweise helfen, die importierten Schlüssel im Web in den Gitolit-Dateien zu speichern. Aus einigen Gründen ist es jedoch fehlgeschlagen. Da die Schlüssel nicht ordnungsgemäß in gitolite gespeichert werden, schlägt der Client/Server fehl Verwenden Sie die Tasten und das Fallback für das Kennwort.

Sie müssen die in gitolite gespeicherten Schlüssel überprüfen und korrigieren, um die Probleme zu beheben.

weitere Informationen finden Sie unter https://groups.google.com/forum/?fromgroups=#!topic/gitlabhq/X0z_9l7L7A8

4
RacsO

Wenn die Installation gut gelaufen ist, kann Ihr Gitlab das Gitolite-Admin-Repo ohne Probleme klonen.
Sie sagen aber, sie besteht die Statusprüfung, was bedeutet, dass Sie für die SSH-Verbindung ein Konto mit dem Namen "Gitlab" verwenden.

Das bedeutet auch, dass jeder Client mit demselben Konto 'gitlab' und nicht mit 'git' ssh haben muss.
Wenn Ihr SSH-Schlüssel also über die Gitlab-Schnittstelle hinzugefügt wurde, können Sie clone/git Push auf einen Remote-Namen Origin setzen, der die Adresse '[email protected]' hätte.

Weitere Informationen zum Debuggen finden Sie in den folgenden Tipps unter " Git Remote SSH einrichten (git-upload-pack/git-receive-pack) ":

Wenn Sie nicht lokal pushen können (auf dem Server selbst, dh auf 'localhost'), versuchen Sie mindestens Folgendes:

ssh -vvvT [email protected]

Es sollte kein Passwort erforderlich sein, da /home/gitlab/.ssh/id_rsa und /home/gitlab/.ssh/id_rsa.pub vorhanden sind.

3
VonC

Ich habe das gleiche Passwort-Prompt erhalten. Mein Problem war, dass ich die Verwendung von SSH auf ein paar Benutzer beschränkt hatte. Ich habe den git-Benutzer zur AllowUsers-Liste sshd_config hinzugefügt, und alles hat gut funktioniert.

2
pixel

Das ist mir in letzter Zeit ziemlich oft passiert - für Arbeitsprojekte würde git mich nach meiner E-Mail und meinem Passwort fragen. Wenn eingegeben, geht es in Ordnung weiter, aber es ist ärgerlich.

Ich kann dies für jede gegebene Anwendung beheben, auf die ich Zugriff habe, mit:

git config remote.Origin.url [email protected]:user_org_or_co/repo_name_itself

z.B.

git config remote.Origin.url [email protected]:smithw/bookmarkapp
1
Michael Durrant

Stellen Sie sicher, dass Ihr Gitlab-Profil Ihren öffentlichen SSH-Schlüssel enthält. Melden Sie sich bei gitlab an, gehen Sie zu Ihrem Profil und wählen Sie die Schaltfläche "öffentlichen Schlüssel hinzufügen". Kopieren Sie den .pub-Inhalt "Schlüsseldatei" und fügen Sie ihn in das Feld "Schlüssel" ein. Es gab einige Versionen von gitlab, bei denen der Fehler auftrat, dass beim Hinzufügen des öffentlichen Schlüssels die Datei authorized_keys nicht aktualisiert wurde. Stellen Sie sicher, dass sich Ihr öffentlicher Schlüssel in der Datei authorized_keys befindet, aber fügen Sie ihn nicht manuell hinzu, nachdem Sie ihn Ihrem Profil hinzugefügt haben. Wenn dies nicht das Problem ist, kann eine der vorherigen Antworten hilfreich sein.

1
phone911

auf dem git server edit /etc/ssh/sshd_config

kommentieren Sie die folgenden Zeilen unter dem Authentifizierungsabschnitt oder fügen Sie sie hinzu: 

PubkeyAuthentication yes

AuthorizedKeysFile %h/.ssh/authorized_keys

gib deinem Server einen Neustart und starte gitlab

1
Bent Cardan

Das mag zu einfach sein, aber ich hatte das gleiche Problem. Ich vermute, es liegt daran, dass localhost als Domänenname verwendet wurde. 

Es klappte, als ich mich von einem anderen Computer wieder bei meinem localhost-Rechner anmeldete und versuchte, einen Commit auszuführen. Es ist ziemlich dumm, aber einen Versuch wert.

0
tsar2512

Ich bin vor kurzem auf das gleiche Problem gestoßen und habe festgestellt, dass das Problem für mich darin bestand, dass SELinux sshd den Zugriff auf die Datei authorized_keys im gitlab-Datenverzeichnis /var/opt/gitlab/ verhinderte.

Um dies zu beheben, bearbeiten Sie /etc/selinux/targeted/contexts/files/file_contexts.homedirs und fügen Sie die Zeile hinzu:

/var/opt/gitlab/\.ssh/.*    system_u:object_r:ssh_home_t:s0

Dann renne:

$ restorecon -Rv /var/opt/gitlab

Quelle: https://serverfault.com/questions/50573/selinux-preventing-passwordless-ssh-login

0
peonicles

Ich stieß auf ein Problem, das ähnliche Symptome zeigte. Mein Problem war, dass ich zwei Computer hinter einem Router habe. Der Router ist so eingestellt, dass er den SSH-Verkehr (Port 22) an Computer 1 weiterleitet. Gitlab ist auf Computer 2 installiert. Ich verwende eine Domäne und eine öffentliche IP-Adresse, um eine Verbindung herzustellen. Wenn ich Push drücke, wird der SSH-Verkehr an Computer 1 geleitet. Auf Computer 1 gibt es einen git-Benutzer, der einfach nur git installiert hat. Computer 1 fordert mich auf, das Passwort des Git-Benutzers einzugeben.

Meine Installation hat auch alle fertigen Prüfungen bestanden.

Ich bin mir nicht sicher, ob Sie das gleiche Problem haben, aber die Symptome sind die gleichen, also dachte ich mir, dass dies helfen könnte.

0
Eebs

Ihre git und gitlab Benutzer sind ohne Passwort?

Wie ist der sshd_config?

prüfen Sie, ob diese Zeile in der Datei enthalten ist: PermitEMptyPassword Yes

Wie auch immer, ich denke, es ist unsicher. In meiner Installation stelle ich 'Ja' ein, klone und halte dann die alte Konfig ... Beim Klonen wird der ssh_key von Benutzer git gespeichert und es wird kein Passwort mehr verlangt. .

Aber jetzt stoße ich auf einen anderen Fehler. Wenn ich zu Push gehe, müssen wir für jeden neuen Benutzer ssh für leeres Push neu konfigurieren und dann die Konfiguration zurückhalten. 

(Ich habe diese Methode immer noch nicht getestet, weil ich herausgefunden habe, dass mein Gitlab keine Repos in git user erstellt: /)

0
Mauro Dias

Es gibt ein Häkchen dafür hier .

Um die Ursache des Problems zu ermitteln, überprüfen Sie die Protokolle auf dem Server über Sudo grep sshd /var/log/auth.log.

Bis zum 13. Dezember 2013 wurde b24d5d festgeschrieben. Das Problem wurde auf dem Vagrant-Entwicklungscomputer durch Überschuss von Berechtigungen für .ssh/ verursacht. Sie müssen haben:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

oder ssh weigert sich, die rsa-Verbindung herzustellen, und Sudo grep sshd /var/log/auth.log sagt:

Authentication refused: bad ownership or modes for file /home/git/.ssh/authorized_keys    

Das Problem wurde gelöst, indem sshd für die Entwicklung auf den Modus "non sctrict" gesetzt wurde, sodass es ordnungsgemäß ausgeführt werden kann, selbst wenn die Berechtigungen zu frei sind.

Wenn Sie dieses Problem mit Bitnami oder einer anderen Konfiguration haben und das Problem schnell lösen möchten, verwenden Sie einfach den vollständigen Pfad.

git clone [email protected]_adress:/full/path/to/project.git

edit: Ich habe vergessen zu erwähnen, es ist sehr wichtig zu überprüfen, ob Sie die SSH-Schlüssel über die Webseite zu git-lab hinzugefügt haben. 

0
musso nero

Ich habe mich einmal damit vermischt. Wenn Sie Sudo git verwenden, bedeutet dies, dass der Git als root gestartet wird. Die Frage wäre: Haben Sie den SSH-Schlüssel für root erstellt und in Gitlab eingefügt?

Ich vermute, dass Sie Ihren SSH-Schlüssel ohne Sudo erstellt haben (was für Ihr normales Konto gilt), den SSH-Publickey in Gitlab einfügen und dann Sudo git ausführen.

Sie können versuchen, git ohne Sudo auszuführen. Wenn Sie Probleme mit der Ordnerberechtigung haben, weshalb Sie Sudo in erster Linie verwendet haben, versuchen Sie, dass Ihr Benutzerkonto Zugriff auf diesen Ordner hat. Oder probieren Sie den Git normalerweise in einem Ordner, für den Sie Schreibrechte haben.

0
Iszuddin Ismail

Dies bedeutet, dass der gitlab-ssh-Server nicht ordnungsgemäß konfiguriert wurde.

Bearbeiten Sie /etc/ssh/sshd_config und stellen Sie sicher, dass:

PasswordAuthentication no
ChallengeResponseAuthentication no

Dies sollte den ssh-Schlüssel nur für Anmeldungen erzwingen, was ebenfalls gute Sicherheitsmaßnahmen darstellt. In vielen neueren Distributionen ist dies bereits standardmäßig aktiviert.

Fragen Sie mich nicht, wenn Sie nach außen gesperrt werden. Offensichtlich ist SO nicht der Ort, an dem Sie gefragt werden, wie Sie ein privates/öffentliches Schlüsselpaar konfigurieren und verwenden.

0
sorin