"Accès refusé" lors de la transmission vers un référentiel distant via SSH

Question

Je suis un débutant avec Git et je semble avoir un problème avec l'envoi vers un référentiel via un réseau.
Voici ce que je fais pour recréer le problème:

1. créer un nouveau dépôt Git sur l'ordinateur pour pousser à

   mkdir ~/git/test.git 
   cd !$ 
   git --bare init 
   

2. Sur mon ordinateur local, je puis créer un nouveau dépôt Git et ajouter un fichier aléatoire à lui:

   mkdir test 
   git init 
   touch TEST 
   git add . 
   git commit -m "initial commit" 
   

3. Ensuite, ajoutez l'ordinateur distant via: git remote add origin ssh://user@site.com/~/git/test.git

4. Ensuite, j'essaie de pousser le dépôt local à la télécommande via: git push origin master

C'est ce que je reçois quand je fais ça:

fatal: protocol error: bad line length character <- sometimes not there 
Access denied 
Access denied 
Access denied 
Access denied 
FATAL ERROR: Server sent disconnect message 
type 2 (protocol error): 
"Too many authentication failures for user" 

J'utilise Cygwin sur une machine XP et essayer de pousser à un serveur UNIX.

Je l'ai également essayé entre mes deux ordinateurs que j'ai à la maison et j'ai le même problème, les deux sont des machines Windows en passant.

J'ai créé connexion sans mot de passe via SSH et je ne peux ssh pas de problème via: ssh user@site.com

J'ai essayé de comprendre cela depuis deux jours, toute aide serait appréciée

Answer 1

I » Je ne suis pas sûr de vos problèmes d'accès, mais le chemin en

git remote add origin ssh://user@site.com/~/git/test.git 

m'inquiète. Qu'obtenez-vous avec

git remote add origin ssh://user@site.com/git/test.git 

?

s'il vous plaît également montrer la sortie de git push -v ...

Answer 2

La question est sans doute que ~ n'augmentera pas correctement lorsque vous l'utilisez dans un ssh URI. Vous devez spécifier le chemin absolu du dépôt git sur la machine distante dans le ssh URI, comme ceci:

ssh://user@site.com/home/user/git/test.git

Answer 3

Essayez d'utiliser

ssh://user@site.com:/home/user/git/test.git 

Answer 4

Dans votre cas, le problème est probablement le ~ personnage. Utilisation:

git remote add origin user@site.com/git/test.git 

Cependant, je l'ai également vu ce problème (toujours sur les machines clientes de Windows) lorsque le nom d'utilisateur (« user @ ») partie a disparu, alors quelqu'un d'autre avec ce problème doit vérifier aussi.

Answer 5

J'avais un problème similaire, mais la solution s'est avérée un peu différente pour ma situation.Le message d'erreur que je recevais était:

$> git push -v unfuddle master 
Pushing to git@subdomain.unfuddle.com:subdomain/repo.git 
Received disconnect from 174.129.246.239: 2: Too many authentication failures for git 
fatal: The remote end hung up unexpectedly 

Je ne pouvais pas comprendre quel était le problème, ssh -vv ne montrait rien non plus. J'avais déjà ce texte dans mon ~/.ssh/config

Host subdomain.unfuddle.com 
    User git 
    IdentityFile ~/.ssh/unfuddle-subdomain-key 

La question se révèle être que le serveur SSH de Unfuddle est configuré pour refuser l'accès après un certain nombre de clés SSH sont essayées. Même si j'avais un jeu IdentityFile spécifique, mon client SSH essayait, pour des raisons inconnues, d'essayer toutes mes clés SSH locales en séquence jusqu'à ce que Unfuddle refuse l'accès. La solution consistait à définir l'option de configuration SSH "IdentitiesOnly" sur "yes", qui indique au client SSH local d'envoyer uniquement ce fichier IdentityFile et aucun autre.

# The fixed ~/.ssh/config line 
Host subdomain.unfuddle.com 
    User git 
    IdentitiesOnly yes 
    IdentityFile ~/.ssh/unfuddle-subdomain-key 

Ref: http://railspikes.com/2010/2/1/fixing-the-heroku-too-many-authentication-failures-for-git-problem

Espérons que cela aide quelqu'un.

James

Answer 6

Une clé de plus pour résoudre un tel problème. Dans notre cas, la raison était le fichier gitolite.conf avec des repositiories et des permissions. Quelqu'un l'a édité avec le bloc-notes de Windows qui a ajouté l'en-tête de nomenclature à lui. Après ce dépôt a eu un comportement très étrange lorsque certains utilisateurs pouvaient mais certains ne pouvaient pas écrire pour obtenir des messages d'accès refusé.