Problema de claves ssh de Ubuntu Github

I followed every step given in this guide: http://help.github.com/linux-key-setup/

When I get to the end I am able to ssh to git@github.com, getting the response:

PTY allocation request failed on channel 0 Hi AlexBaranosky! You've successfully authenticated, but GitHub does not provide shell access. Connection to github.com closed

But when I go to clone my repo it fails saying:

Permission denied (publickey). fatal: The remote end hung up unexpectedly

I've used Github a lot, but this is my first use of it from an Ubuntu computer, is there something I am missing here?

Cualquier ayuda es muy apreciada.

Alex

EDIT:

contenido de ssh -v git@github.com

alex@ubuntu:~/proj$ ssh -v git@github.com
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 no-more-sessions@openssh.com
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 eow@openssh.com 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

Output from running: git clone git@github.com:AlexBaranosky/Sportello.git

fatal: could not create work tree dir 'Sportello'.: Permission denied

preguntado el 09 de enero de 11 a las 05:01

Huh? Why the -1? If it belongs somewhere else, say so. -

3 Respuestas

Did you run all of the commands in the Github guide as root? Given the solution you noted already, this is the only scenario I can imagine, currently.

Working as root, in any aspect, is insanely dangerous, and should be avoided if at all possible.

I highly advise re-running those instructions as your own user. I second Ray's suggestion of trying it again with -v, we can help you from that point. Using root at all, especially for this development+push process, is just dangerous. All it takes is for you to delete a tree (rm -rf tree*) and accidentally add a space between tree and *, bam, tons of content lost. And you could do a lot worse too.

Respondido el 09 de enero de 11 a las 10:01

everything in the link example works fine, then I go to clone my repo: - Alex Baranosky

alex@ubuntu:~/proj$ git clone git@github.com:AlexBaranosky/Sportello.git fatal: could not create work tree dir 'Sportello'.: Permission denied - Alex Baranosky

I'll post results of ssh -v git@github.com in the question text above, thanks for the help. - Alex Baranosky

AHA! So I must have used sudo mkdir proj, when I created the proj folder? So I deleted /proj and remade it, and did the git clone, and it worked! Thanks for all the help, really appreciate it. - Alex Baranosky

You're welcome. This is why you don't work as root nor excessively abuse sudo :). - VxJasonxV

ssh maybe trying multiple keys until it finds one that works. (confusing but robust)

in verbose mode:

ssh -v git@github.com

you will see which key ssh is using to authenticate.

You can then rejig the keys or add the correct filename to ~/.ssh/config for host github.com

¡Salud

Ray

Respondido el 09 de enero de 11 a las 09:01

Do you think it has something to do with this?: anujgakhar.com/2010/12/28/… All this sudo stuff is a little confusing at first. - Alex Baranosky

Perhaps the first key it tried for root was the right one and your other user had a different order? ssh -v on both users might help to answer that. - Ray Vahey

I was on a newly configured Ubuntu machine and had to make sure my SSH keys were properly configured. http://help.github.com/linux-set-up-git/

Respondido 17 Oct 11, 18:10

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.