Ubuntu Github ssh-Schlüssel Problem
Folgte ich jeden Schritt dieser Anleitung:
http://help.github.com/linux-key-setup/
Wenn ich am Ende bin ich in der Lage, ssh [email protected], immer die Antwort:
PTY allocation request failed on channel 0
Hi AlexBaranosky! Sie haben erfolgreich authentifiziert, aber GitHub macht nicht stellen Sie shell-Zugriff.
Verbindung zu github.com geschlossen
Aber wenn ich auf mein Klon-repo scheitert es nämlich:
Permission denied (publickey).
fatal: The remote end hung up unerwartet
Ich verwendet habe, Github, eine Menge, aber dies ist mein Erster Einsatz von einem Ubuntu-Rechner, gibt es etwas, was ich hier vermisst?
Jede Hilfe wird sehr geschätzt.
Alex
EDIT:
Inhalt ssh -v [email protected]
alex@ubuntu:~/proj$ ssh -v [email protected]
OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com [207.97.227.239] port 22.
debug1: Connection established.
debug1: identity file /home/alex/.ssh/identity type -1
debug1: identity file /home/alex/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alex/.ssh/id_dsa 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.3p1 Debian-3ubuntu4
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 /home/alex/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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 public key: /home/alex/.ssh/id_rsa
debug1: Remote: Forced command: gerve AlexBaranosky
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 277
debug1: Remote: Forced command: gerve AlexBaranosky
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8
PTY allocation request failed on channel 0
Hi AlexBaranosky! You've successfully authenticated, but GitHub does not provide shell access.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype [email protected] reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to github.com closed.
Transferred: sent 2592, received 2904 bytes, in 0.1 seconds
Bytes per second: sent 44942.9, received 50352.7
debug1: Exit status 1
Ausgabe vom laufen: git clone [email protected]:AlexBaranosky/Sportello.git
fatal: could not create work tree dir 'Sportello'.: Permission denied
InformationsquelleAutor Alex Baranosky | 2011-01-09
Du musst angemeldet sein, um einen Kommentar abzugeben.
Haben Sie laufen alle Befehle in der Github Anleitung als root? Angesichts der Lösung, die Sie bereits erwähnt, ist dies das einzige Szenario, das ich mir vorstellen kann, derzeit.
Als root arbeitet, in jedem Aspekt, ist wahnsinnig gefährlich und sollte vermieden werden, wenn überhaupt möglich.
Ich sehr empfehlen neu-die Ausführung dieser Anweisungen, wie Sie Ihre eigenen Benutzer. Ich schließe mich Ray ' s Vorschlag versuchen es wieder mit -v, wir können Ihnen helfen, von diesem Punkt aus. Mit root an alle, vor allem für diese Entwicklung ist+push-Verfahren, ist einfach nur gefährlich. Alles was es braucht ist für Sie zu löschen ein Baum (
rm -rf tree*) und versehentlich ein Leerzeichen zwischen Baum und * bam, Tonnen von Inhalten verloren. Und Sie tun könnte eine Menge schlechter zu.alles, was in dem link-Beispiel funktioniert gut, dann gehe ich zu mein Klon repo:
Ist ~/proj root gehören?
AHA! Also ich muss haben verwendet sudo mkdir proj, wenn ich die erstellt habe proj Ordner? Also habe ich gelöscht /proj und erneuert es und Tat das git clone, und es funktionierte! Vielen Dank für all die Hilfe wirklich zu schätzen.
Du bist herzlich willkommen. Dies ist der Grund, warum Sie nicht als root arbeiten, noch übermäßig Missbrauch sudo :).
InformationsquelleAutor VxJasonxV
ssh vielleicht versuchen, mehrere Schlüssel aus, bis er eine findet, die funktioniert. (verwirrend, ist aber robust)
im verbose-Modus:
werden Sie sehen, welche Schlüssel ssh anmelden.
Können Sie dann rejig die Tasten oder fügen Sie die richtigen Dateinamen ~/.ssh/config host github.com
Cheers
Ray
Vielleicht die erste Taste, die es versucht, die Wurzel war, die richtige und Ihr anderen user hatte eine andere Reihenfolge? ssh -v bei Usern helfen könnte, zu beantworten.
InformationsquelleAutor Ray Vahey
War ich auf einem neu konfigurierten Ubuntu-Rechner und musste sicherstellen, dass meine SSH-keys wurden korrekt konfiguriert. http://help.github.com/linux-set-up-git/
InformationsquelleAutor Rian Rainey