Ik heb zojuist GitLab geïnstalleerd.
Ik heb een project gemaakt met de naam project-x.
Ik heb weinig gebruikers aangemaakt en aan het project toegewezen.
Nu probeerde ik te klonen:
git clone [email protected]:project-x.git
Ik werd om een wachtwoord gevraagd.
Welk wachtwoord moet ik gebruiken?
Antwoord 1, autoriteit 100%
Niet strikt gerelateerd aan het huidige scenario. Soms, wanneer u om een wachtwoord wordt gevraagd, is dit omdat u het verkeerde* oorspronkelijke formaat hebt toegevoegd (HTTPS in plaats van SSH)
HTTP(S)-protocol wordt vaak gebruikt voor openbare repo’s met een sterke gebruikersnaam+pass
SSH-verificatie is gebruikelijker voor interne projecten waar u kunt verifiëren met een ssh-sleutelbestand en een eenvoudige wachtwoordzin
GitLab-gebruikers gebruiken eerder het SSH-protocol
Bekijk uw externe informatie met
git remote -v
Als u een HTTP(S)-adres ziet, is dit de opdracht om dit te wijzigen in SSH:
git remote set-url origin [email protected]_domain.com/example-project.git
Antwoord 2, autoriteit 93%
Ik werd om een wachtwoord gevraagd.
Dat zou niet moeten.
Als je de juiste openbare/privésleutel hebt die een gebruiker vertegenwoordigt die geautoriseerd is voor toegang tot project-x, dan zal gitlab je nergens om vragen.
Maar dat veronderstelt dat ssh -vT [email protected]eerst werkt.
Antwoord 3, autoriteit 33%
De oplossing van https://github.com/gitlabhq/gitlab-shell/issues/46werkte voor mij.
Door de rechten in te stellen:
chmod 700 /home/git/.ssh
chmod 600 /home/git/.ssh/authorized_keys
wachtwoordprompt verdwijnt.
Antwoord 4, autoriteit 9%
Ik had hetzelfde probleem bij het gebruik van een sleutel van 4096 bits:
$ ssh-keygen -t rsa -C “GitLab” -b 4096
$ ssh -vT git@gitlabhost
…
debug1: openbare sleutel aanbieden: /home/user/.ssh/id_rsa
debug1: Authenticaties die kunnen doorgaan: publickey,password
debug1: privésleutel proberen: /home/user/.ssh/id_dsa
debug1: privésleutel proberen: /home/user/.ssh/id_ecdsa
debug1: Volgende authenticatiemethode: wachtwoord
git@gitlabhost’s wachtwoord:
Verbinding verbroken door host
Maar met de 2048-bits sleutel (de standaardgrootte), maakt ssh verbinding met gitlab zonder om een wachtwoord te vragen (na het toevoegen van de nieuwe pub-sleutel aan de gitlab ssh-sleutels van de gebruiker)
$ ssh-keygen -t rsa -C “GitLab”
$ ssh -vT git@gitlabhost
Welkom bij GitLab, Joe Gebruiker!
Antwoord 5, autoriteit 9%
Dit kan gebeuren als de host een ‘-‘ in zijn naam heeft. (Ook al is dit legaal volgens RFC 952.) (Getest met Git Bash onder Windows 10 met git 2.13.2.)
ssh vraagt me om een wachtwoord voor elke host die toevallig een ‘-‘ in zijn naam heeft. Dit lijkt puur een probleem te zijn met het ontleden van het ssh-configuratiebestand, omdat het toevoegen van een alias aan ~/.ssh/config (en het gebruik van die alias in mijn git externe url’s) het probleem heeft opgelost.
Met andere woorden, probeer iets als het volgende in je C:/Users/{username}/.ssh/config
te zetten
Host {a}
User git
Hostname {a-b.domain}
IdentityFile C:/Users/{username}/.ssh/id_rsa
en waar je een afstandsbediening van het formulier hebt
origin [email protected]:repo-name.git
wijzig de url om het volgende formulier te gebruiken
git remote set-url origin git@a:repo-name.git
Antwoord 6, autoriteit 9%
Controleer na het toevoegen van de nieuwe SSH-sleutel in GitLab of de “git”-groep is opgenomen in SSHD AllowGroups(voor Debian /etc/ssh/sshd_config). Zo niet, voeg het dan toe en herstart sshd (systemctl restart ssh).
Test het met ssh -vT [email protected]zoals hierboven voorgesteld.
Antwoord 7, autoriteit 9%
Mijn probleem was dat ik een DNS-vermelding had voor gitlab.example.comom naar mijn load balancer te verwijzen. Dus toen ik het commando ssh [email protected]probeerde, maakte ik echt verbinding met de verkeerde machine.
Ik heb iets ingevoerd in mijn bestand ~/.ssh/config:
Host gitlab.example.com
Hostname 192.168.1.50
Dat was veel tijdverspilling…
Antwoord 8, autoriteit 7%
Om nog een reden aan de lijst toe te voegen … in mijn geval ontdekte ik dat dit probleem werd veroorzaakt door een SELinux-permissieprobleem op de server. Dit is de moeite waard om te controleren of uw server Fedora / CentOS / Red Hat draait. Om dit scenario te testen, kunt u het volgende uitvoeren:
Client: ssh -vT git@<gitlab-server>— vraagt om wachtwoord
Server: sudo setenforce 0
Client: ssh -vT git@<gitlab-server>— slaagt
Server: sudo setenforce 1
In mijn geval had het authorized_keys-bestand van de gitlab/git-gebruiker de verkeerde SELinux-bestandscontext en kreeg de ssh-service geen toestemming om het te lezen. Ik heb dit aan de serverzijde als volgt opgelost:
sudo semanage fcontext -a -t ssh_home_t /gitlab/.ssh/
sudo semanage fcontext -a -t ssh_home_t /gitlab/.ssh/authorized_keys
sudo restorecon -F -Rv /gitlab/.ssh/
En toen kon ik zoals verwacht git cloneaan de clientzijde.
Antwoord 9, autoriteit 5%
Ik had de juiste openbare/privésleutel, maar het leek alsof het toch niet werkte (kreeg dezelfde fouten, vroegen om het git-gebruikerswachtwoord). Na een herstart van de computer werkte het echter!
Antwoord 10, autoriteit 5%
In mijn geval gebruikte ik een sleutelpaar dat niet de standaardnamen id_rsaen id_rsa.pubhad.
Het produceren van sleutels met deze namen loste het probleem op, en ik vond het eigenlijk kijkend naar de uitvoer van ssh -vT my_gitlab_address. Vreemd feit: het werkte op één computer met Ubuntu, maar niet op andere met verschillende distributies en oudere versies van OpenSSH.
Antwoord 11, autoriteit 2%
Dezelfde oplossing voor Windows-computer:
- Genereer SSH-sleutel en voeg sleutel toe aan Git lab-server
- Zorg ervoor dat er 2 SSH-sleutelbestanden in de map /.ssh staan (bijv. C:\Users\xxx.ssh)
Klonen zou succesvol moeten zijn zonder wachtwoord vereist.
Antwoord 12, autoriteit 2%
Ik gebruik een mac.gitlabdie is geïnstalleerd op een centos-server.
Ik heb alle bovenstaande methoden geprobeerd en vond het definitieve antwoord voor mij:
fout:
ssh-keygen -t rsa
rechts:
ssh-keygen -t rsa -C "[email protected]" -b 4096
Antwoord 13, autoriteit 2%
Op Windows 10 met gebruik van de terminal onder VS Code kreeg ik een prompt voor “git@gitlab’s wachtwoord:” toen ik probeerde:
git push -u origin --all
Ik had mijn ssh-inloggegevens in Windows en in gitlab vastgesteld, maar ik had Windows 10 bash key-gen gebruikt om dit te doen. De oplossing was toen om bash aan te roepen in de VS-codeterminal en het commando opnieuw uit te voeren.
bash
git push -u origin --all
Het is gelukt.
Om te voorkomen dat ik bash/git handmatig moet gebruiken, plaats ik een symbolische link tussen de windows .ssh/id_rsa en de bash shell .ssh/id_rsa:
C:\Users\bruce\.ssh>mklink id_rsa C:\Users\bruce\AppData\Local\lxss\home\bruce\.ssh\id_rsa
VS Code Git menu-acties (push, pull, etc.) werken nu met gitlab
Antwoord 14, autoriteit 2%
Als git cloneom een wachtwoord vraagt, is er waarschijnlijk een probleem met je lokale computer. Mijn probleem was dat ik een aangepast pad gebruikte om de ssh-sleutel op te slaan en dat pad was niet zichtbaar voor git. Gebruik het standaardpad dat u wordt voorgesteld of voeg het bestand toe op de aangepaste locatie met ssh-add <file>
Antwoord 15, autoriteit 2%
In mijn geval bleek het gitlab in dockerte draaien en poorttoewijzing 4022/22 te hebben.
Dus ik moet ~/.ssh/configbewerken om de poort te specificeren via Port 4022, bijvoorbeeld:
Host gitlab-local
Hostname 192.168.1.101
User git
Port 4022
IdentityFile ~/.ssh/id_rsa.pub
# LogLevel DEBUG3
Antwoord 16
Ik had hetzelfde probleem,
Ik heb veel tijd besteed aan zoeken!
Ik kwam op het idee om Eclipse te gebruiken om het project uit GitLab te importeren.
Zodra het project correct is geïmporteerd, heb ik de vergelijking gemaakt tussen de configuratie van:
- de Git-ripository van het project die ik heb geïmporteerd in Eclippe, (“in Eclipse”, Git Repository, in myprojectRepo / Working Directory / .git / config)
- degene die is gemaakt in .git / config, daar wilde ik mijn project pushen met git: git push … en vroeg me om een wachtwoord.
Verrassing: de afstandsbediening heeft niet in beide gevallen hetzelfde.
Ik gaf dezelfde als die in eclipse en alles werkt.
Antwoord 17
Had hetzelfde probleem in Windows 10 (weet niet of dit relevant is).
Als alles correct was ingesteld, lukte het ssh -vT git@myservercommando, maar Gitlab vroeg nog steeds om mijn wachtwoord.
Het verwijderen en vervolgens opnieuw maken van de sleutel in Gitlab was de truc voor mij.
Antwoord 18
Op mijn Windows 10-computer was het omdat de SSH_GIT-omgevingsvariabele niet was ingesteld om de stopverf-plink te gebruiken die ik op mijn computer had geïnstalleerd.
Antwoord 19
Als je meerdere sleutels via ssh op je systeem hebt ingesteld (op mijn apparaat draait Windows 10), kun je dit probleem meestal tegenkomen, de oplossing is om:
Voorwaarde: stel uw SSH-sleutels in zoals aangegeven door GitLab
- open /c/Users//.ssh/config bestand met Notepad++ of je favoriete editor
- plak het volgende erin.
Gastheer
IdentityFile ~/.ssh/
Let op, er is een spatie voor de tweede regel, erg belangrijk om te voorkomen dat deze oplossing niet werkt.
Antwoord 20
als u zeker weet dat u de inhoud van key.pub naar GitLab heeft geüpload, doet u het volgende:
1- Open Git Bash “Niet CMD”
2- Blader naar de oplossingsmap “CD-pad”
3- Typ Git Init
4- Typ Git Add .
4- Typ Git Commit
6- Typ Git Push
en het zal werken..
nog een tip:
zorg ervoor dat het pad van het bestand waar je de sleutel hebt gekopieerd correct is en gelijk is aan hetzelfde pad dat op CMD werd getoond bij het maken van de sleutels
Antwoord 21
Voor het geval iemand hetzelfde probleem had als het mijne.
Ik draaide de GitLab-server in docker env en ik wilde een ssh-verbindingspoort instellen als 2202, niet 22, dus ik bond de 2202-poort van de host aan de 2202-poort van de docker-container. Ik deed het niet voor 22.
En toen vergat ik dat ik de standaard verbindingspoort van ssh moest veranderen … Dus ik had dezelfde fout als deze vraagschrijver.
Eerst opende ik poort #22 en het werkte, dus daarna veranderde ik de ssh-verbindingspoort naar 2202 en het werkte allemaal prima.
Het was stom van mezelf, maar het kan andere dummies helpen 🙂