Pourquoi un cap déployer donnant la Permission denied (publickey)?

Ok, je suis confus au sujet de quelque chose... je suis capable d'en commettre à mon dépôt github, mais quand j'ai essayer de faire un cap deploy de mon dossier local de mon serveur de test-je obtenir Permission denied (publickey).

Si je lance ssh [email protected] j'ai fait une erreur PTY allocation request failed on channel 0

Donc quelque chose ici est faux.

Si je lance ssh -vT [email protected] j'obtiens:

OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/myuser/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com [207.97.227.239] port 22.
debug1: Connection established.
debug1: identity file /Users/myuser/.ssh/id_rsa type 1
debug1: identity file /Users/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/myuser/.ssh/id_dsa type -1
debug1: identity file /Users/myuser/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5github2
debug1: match: OpenSSH_5.1p1 Debian-5github2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /Users/myuser/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/myuser/.ssh/github_rsa
debug1: Remote: Forced command: gerve technomad
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Remote: Forced command: gerve technomad
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([207.97.227.239]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
Hi technomad! You've successfully authenticated, but GitHub does not provide shell access.
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2384, received 2888 bytes, in 0.1 seconds
Bytes per second: sent 42630.8, received 51643.3
debug1: Exit status 1

Mes clés sont dans le ~/.ssh dossier, alors quel est le problème, et pourquoi suis-je en mesure de s'engager dans le référentiel si il y a une question-clé??

Mise à JOUR:
J'ai remarqué quelque chose quand je suis allé dans mon .ssh dossier. Il y a une nouvelle paire de clés a été créé lorsque j'ai installé Github pour Mac... pourquoi ne pouvait-il pas simplement utiliser mes clés, je ne sais pas.

InformationsquelleAutor GiH | 2011-11-01

19

Je voudrais assurez-vous que votre serveur de test a un accès ssh github. Exécuter la même commande "ssh -vT [email protected]" par l'intermédiaire d'un terminal sur votre serveur de test; cela permettra de déterminer si elle est ssh problème sur la machine distante.
- Qui a travaillé merci :), j'ai été donnant sur la partie. Mais je ne sais toujours pas pourquoi "ssh [email protected]" est de retour "PTY demande d'allocation a échoué sur le canal 0"?
- Pouvez-vous en ssh à d'autres serveurs sans que le problème de surfaçage?
- oui, quand je ssh sur mon serveur, il fonctionne très bien, son seul "ssh [email protected]", en fait si je fais "ssh -T [email protected]" il fonctionne très bien aussi... alors pourquoi ne pas travailler sans l'option-T? Pourrait-il être un problème avec Mac OSX lion?
- Je voudrais vérifier ce thread: comments.gmane.org/gmane.os.cygwin/125243. HTH.
- Merci, vous êtes en lien m'a finalement conduit à cette réponse de stackoverflow.com/questions/3844393/.... Pour citer la réponse "la" PTY demande d'allocation a échoué " est un leurre à l'égard de GitHub authentification (c'est le résultat d'essayer de manière interactive connexion à GitHub quand la seule SSH service qu'ils offrent est non-interactive Git-sur-SSH; l'authentification fonctionne, il suffit de ne pas fournir interactive, “shell” de service)."
- GitHub ne fournit pas d'accès shell, d'où le PTY répartition de l'erreur. C'est censé arriver.
- Juste une petite remarque que cela peut être un hareng rouge si vous avez set :ssh_options, forward_agent: true (ce qui est une bonne façon de traiter avec les clés dans capistrano). Si vous êtes à l'aide de l'agent de transfert, vous n'aurez pas nécessairement être en mesure de faire du ssh vers github à partir du serveur distant, même si tout le reste fonctionne, ce qui signifie que le problème d'origine est probablement liée à local ssh config.
InformationsquelleAutor Dave Bettin
115

J'ai eu à faire ce qui suit:
```
   $ ssh-add -D   #remove existing identities
   $ ssh-agent    #copy the lines & run them
   $ ssh-add      #uses the output from above
```
- Exécutez ces commandes sur votre machine locale
- C'est la réponse exacte à ce problème. Pas besoin d'ajouter de clé ssh sur votre machine. Il suffit d'exécuter la commande ci-dessus et de la faire... Merci @olore
- Mais quelle est la raison derrière tout cela, et ce que cette commande n'a résoudre ce problème?
- La commande ci-dessus ajoute le RSA/DSA identités à l'agent d'authentification, qui vérifie l'autorisation lorsque vous déployez. Pour une raison que si les identités ne sont pas ajoutés avant d'exécuter la commande deploy, vous obtiendrez l'erreur permission denied. Pour moi, chaque fois que je redémarre mon ordinateur, j'ai besoin de taper les commandes ci-dessus pour le faire fonctionner. J'ai pensé que ma clé publique ssh n'était pas ajouté automatiquement après chaque redémarrage. Donc, j'ai utilisé ssh-add -K après les commandes ci-dessus pour ajouter de la sortie d'un Trousseau de clés. Après que mon problème a été résolu de façon permanente.
- J'ai eu un énorme problème avec elle dans Debian avec une clé avec un nom différent de id_rsa. J'ai juste fait ssh-add $HOME/.ssh/[key_name].
- Cela a fonctionné pour moi. J'ai été l'obtention de l'erreur après le transfert de mon système de fichiers vers un nouvel ordinateur.
InformationsquelleAutor olore
32

J'obtiens cette erreur parfois, et je viens de type $ ssh-add -k pour ajouter mon identité, puis elle travaille. Vous ne savez pas exactement pourquoi cela fonctionne ou pourquoi le message d'erreur ne le suggèrent, mais il vient toujours à la rescousse!

InformationsquelleAutor Catfish
2

J'ai rencontré le même problème après l'installation de GitHub pour Mac OS X. L'application a créé une nouvelle clé privée ssh dans ~/.ssh/github_rsa et de l'ajouter à l'authentification ssh agent.

Vérifier les clés ssh authentification de l'agent a mis en cache:
```
$ ssh-add -l
2048 63:0c:a6:51:63:c1:35:76:5d:02:77:97:39:48:0e:4a /Users/jiangxin/.ssh/github_rsa (RSA)
```
Chaque fois que vous vous connectez à github.com ou une autre ssh services, cette clé est utilisée en premier.

Effacer le cache des clés de ssh-agent à l'aide de cette commande:
```
$ ssh-add -D
```
Maintenant le client ssh devrait fonctionner normalement, à l'aide de la clé définie dans ~/.ssh/config ou ~/.ssh/id_rsa.

InformationsquelleAutor Jiang Xin
1

Si vous utilisez MAC. Peut-être que votre clé ssh n'est pas ajouté à l'authentification de l'agent. Commande suivante qui fera
```
ssh-add path_to_private_key
```
par exemple
```
ssh-add ~/.ssh/id_rsa
```
InformationsquelleAutor Rajat Bansal
0

L'erreur est parce que, ssh-add ne sais pas comment parler avec l'agent d'authentification.
Le problème peut être résolu par la mise en SSH_AUTH_SOCK variable d'environnement.

Si vous exécutez ssh-agent, vous devriez obtenir une sortie comme ceci:
```
SSH_AUTH_SOCK=/tmp/ssh-agVZL13989/agent.13989; export SSH_AUTH_SOCK;
SSH_AGENT_PID=13990; export SSH_AGENT_PID;
echo Agent pid 13990;SSH_AUTH_SOCK=/tmp/ssh-agVZL13989/agent.13989; export SSH_AUTH_SOCK;
SSH_AGENT_PID=13990; export SSH_AGENT_PID;
echo Agent pid 13990;
```
Exécuter ceci :
```
eval $(ssh-agent)
```
Et puis :
```
ssh-add -D
```
- Chers Sankalp, votre réponse est très court et devrait fournir des informations supplémentaires afin de les empêcher d'être supprimé (il a déjà été signalée pour la suppression par un autre utilisateur)
- Merci @furins.. je vais écrire quelques infos.
- pourquoi ssh-add -D? Ceci est juste va supprimer votre identité. Ne pense pas que cela va aider à résoudre le problème.
InformationsquelleAutor Sankalp Singha

Vous devez vous connecter pour publier un commentaire.