Warum wird eine Cap-Bereitstellung, die die Berechtigung erteilt, verweigert (Publickey)?

Lesezeit: 7 Minuten

Benutzer-Avatar
GiH

Ok, ich bin wegen etwas verwirrt … Ich kann mich problemlos auf mein Github-Repository festlegen, aber wenn ich versuche, a cap deploy von meinem lokalen Ordner auf meinen Staging-Server bekomme ich Permission denied (publickey).

Wenn ich laufe ssh [email protected] Ich bekomme tatsächlich einen Fehler PTY allocation request failed on channel 0

Hier stimmt also etwas nicht.

Wenn ich laufe ssh -vT [email protected] Ich bekomme:

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

Meine Schlüssel befinden sich im Ordner ~/.ssh, also was ist das Problem, und warum kann ich mich auf das Repository festlegen, wenn es ein Schlüsselproblem gibt?

AKTUALISIEREN:
Ich habe etwas bemerkt, als ich in meinen .ssh-Ordner gegangen bin. Es gibt ein neues Schlüsselpaar, das erstellt wurde, als ich Github für Mac installiert habe … warum konnte es nicht einfach mein vorhandenes Schlüsselpaar verwenden, das ich nicht weiß.

Folgendes musste ich tun:

   $ ssh-add -D   #remove existing identities
   $ ssh-agent    #copy the lines & run them
   $ ssh-add      #uses the output from above

  • Dies ist die genaue Antwort auf das Problem. Sie müssen keinen SSH-Schlüssel auf Ihrer Bühnenmaschine hinzufügen. Führen Sie einfach den obigen Befehl aus und fertig … Danke @olore

    – Rahul Chaudhari

    14. Juli 2014 um 7:15 Uhr

  • Aber was ist der Grund dafür und was hat dieser Befehl getan, um das zu lösen?

    – Rahul Chaudhari

    14. Juli 2014 um 7:32 Uhr

  • Der obige Befehl fügt die RSA/DSA-Identitäten zum Authentifizierungsagenten hinzu, der die Berechtigung bei der Bereitstellung prüft. Wenn die Identitäten nicht hinzugefügt werden, bevor Sie den Bereitstellungsbefehl ausführen, erhalten Sie aus irgendeinem Grund den Fehler „Berechtigung verweigert“. Für mich musste ich jedes Mal, wenn ich meinen Computer neu starte, die obigen Befehle eingeben, damit es funktioniert. Ich stellte fest, dass mein öffentlicher SSH-Schlüssel nach jedem Neustart nicht automatisch hinzugefügt wurde. Also habe ich verwendet ssh-add -K nach den obigen Befehlen, um die Ausgabe zum Schlüsselbund hinzuzufügen. Danach war mein Problem dauerhaft gelöst.

    – Brian Russel Davis

    25. Mai 2016 um 20:53 Uhr

  • Ich hatte ein großes Problem damit in Debian mit einem Schlüssel mit einem anderen Namen als id_rsa. Ich habe es gerade getan ssh-add $HOME/.ssh/[key_name].

    – Fermoga

    25. Juli 2017 um 6:48 Uhr

  • Das hat bei mir funktioniert. Ich habe den Fehler erhalten, nachdem ich mein Dateisystem auf einen neuen Computer übertragen hatte.

    – Daniel Ristic

    14. August 2017 um 12:47 Uhr

Ich bekomme diesen Fehler manchmal und ich tippe einfach $ ssh-add -k um meine Identität hinzuzufügen und dann funktioniert es. Ich bin mir nicht sicher, warum das funktioniert oder warum die Fehlermeldung es nicht vorschlägt, aber es kommt immer zur Rettung!

Ich würde sicherstellen, dass Ihr Staging-Server ssh-Zugriff auf github hat. Führen Sie denselben Befehl „ssh -vT [email protected]“ über ein Terminal auf Ihrem Staging-Server aus; Dies hilft festzustellen, ob es sich um ein SSH-Problem auf dem Remote-Computer handelt.

  • Das hat funktioniert danke :), ich habe diesen Teil übersehen. Aber ich weiß immer noch nicht, warum “ssh [email protected]” “PTY-Zuweisungsanfrage auf Kanal 0 fehlgeschlagen” zurückgibt?

    – GiH

    1. November 2011 um 20:16 Uhr

  • Können Sie ssh zu anderen Servern senden, ohne dass dieses Problem auftaucht?

    – David Bettin

    1. November 2011 um 20:35 Uhr

  • Ich würde mir diesen Thread anschauen: comments.gmane.org/gmane.os.cygwin/125243. HTH.

    – David Bettin

    2. November 2011 um 15:03 Uhr

  • Danke, Ihr Link führte mich schließlich zu dieser Antwort stackoverflow.com/questions/3844393/…. Um die Antwort zu zitieren: “Die ‘PTY-Zuweisungsanforderung fehlgeschlagen’ ist ein Ablenkungsmanöver in Bezug auf die GitHub-Authentifizierung (es ist das Ergebnis des Versuchs, sich interaktiv bei GitHub anzumelden, wenn der einzige SSH-Dienst, den sie anbieten, nicht interaktives Git-over-SSH ist; die Authentifizierung funktioniert, sie bieten nur keinen interaktiven „Shell“-Dienst).”

    – GiH

    2. November 2011 um 15:43 Uhr

  • Nur eine kurze Anmerkung, dass dies ein Ablenkungsmanöver sein kann, wenn Sie es haben set :ssh_options, forward_agent: true (was eine gute Möglichkeit ist, mit Schlüsseln in Capistrano umzugehen). Wenn Sie die Agentenweiterleitung verwenden, können Sie vom Remote-Server nicht unbedingt ssh zu github senden, selbst wenn alles andere funktioniert, was bedeutet, dass das ursprüngliche Problem wahrscheinlich mit der lokalen ssh-Konfiguration zusammenhängt.

    – Däne

    7. Juli 2014 um 16:29 Uhr

Benutzer-Avatar
Jiang Xin

Ich bin nach der Installation von GitHub für Mac OS X auf das gleiche Problem gestoßen. Die Anwendung hat einen neuen privaten SSH-Schlüssel in ~/.ssh/github_rsa erstellt und dem SSH-Authentifizierungsagenten hinzugefügt.

Überprüfen Sie, welchen Schlüssel der ssh-Authentifizierungsagent zwischengespeichert hat:

$ 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)

Immer wenn Sie sich mit github.com oder einem anderen SSH-Dienst verbinden, wird dieser Schlüssel zuerst verwendet.

Löschen Sie die zwischengespeicherten Schlüssel von ssh-agent mit diesem Befehl:

$ ssh-add -D

Jetzt sollte der SSH-Client normal funktionieren und den in ~/.ssh/config oder ~/.ssh/id_rsa definierten Schlüssel verwenden.

Wenn Sie MAC verwenden. Möglicherweise wird Ihr SSH-Schlüssel nicht zum Authentifizierungsagenten hinzugefügt. Der folgende Befehl wird dies tun

ssh-add path_to_private_key

zum Beispiel

ssh-add ~/.ssh/id_rsa

Der Fehler liegt daran, dass ssh-add nicht weiß, wie es mit dem Authentifizierungsagenten kommunizieren soll. Das Problem kann gelöst werden, indem die Umgebungsvariable SSH_AUTH_SOCK gesetzt wird.

Wenn Sie ssh-agent ausführen, sollten Sie eine Ausgabe wie diese erhalten:

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;

Führen Sie dies aus:

eval $(ssh-agent)

Und dann :

ssh-add -D

1283530cookie-checkWarum wird eine Cap-Bereitstellung, die die Berechtigung erteilt, verweigert (Publickey)?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy

Contact - Terms and Conditions - Privacy Policy