Por que o encaminhamento de agente ssh não está funcionando?

57

No meu próprio computador, executando o MacOSX, tenho isso em ~ / .ssh / config

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1 é uma máquina virtual executando o Ubuntu 12.04. Eu ssh para isso assim:

ssh pupeno@b1

e fico logado sem ser solicitada uma senha porque já copiei minha chave pública. Devido ao encaminhamento, devo poder enviar ssh para pupeno @ b1 a partir de b1 e deve funcionar, sem me pedir uma senha, mas não. Ele me pede uma senha.

o que estou perdendo?

Esta é a saída detalhada do segundo ssh:

pupeno@b1:~$ ssh -v pupeno@b1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to b1 [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pupeno/.ssh/id_rsa type -1
debug1: identity file /home/pupeno/.ssh/id_rsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_dsa type -1
debug1: identity file /home/pupeno/.ssh/id_dsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 35:c0:7f:24:43:06:df:a0:bc:a7:34:4b:da:ff:66:eb
debug1: Host 'b1' is known and matches the ECDSA host key.
debug1: Found key in /home/pupeno/.ssh/known_hosts:1
debug1: ssh_ecdsa_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,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password
pupeno@b1's password:

— pupeno
fonte

94

Acontece que minha chave não estava no agente e foi corrigida:

OS X :

ssh-add -K

Linux / Unix :

ssh-add -k

Você pode listar as chaves carregadas usando:

ssh-add -l

ssh-add -L # for more detail

— pupeno
fonte

5

Note-se que ssh-add -Ké específico para OS X.

— Roger Lipscombe

Você precisa fazer isso a cada reinicialização?

— Krauser

8

Verifique se seus ./ssh/id_rsa .ssh/id_dsa .ssh/id_ecdsaarquivos têm as permissões corretas que devem pertencer ao seu usuário e estar com o modelo 600.
Verifique se a chave pública correta está pupeno/.ssh/authorized_keysativada em b1 e verifique se authorized_keyshá uma quebra de linha no final da chave.
Verifique se você tem o ssh-agent em execução, tente carregar as chaves via ssh-add
Experimente a autenticação e o encaminhamento baseados em GSSAPI com ssh -K

— Daniel Prata Almeida
fonte

A permissão das chaves está correta e a chave em allowed_keys está correta (caso contrário, acho que eu teria problemas para conectar-se em primeiro lugar).

— pupeno

Você tinha o ssh-agent em execução? O que acontece quando você faz um ssh-add e depois ssh -A pupeno @ b1 e depois ssh pupeno @ b1?

— Daniel Prata Almeida

Por que você não atualiza a resposta para mencionar ssh-add -K e eu aceito a sua em vez da minha (já que as informações foram postadas quase simultaneamente).

— pupeno

6

Eu tive um problema com o servidor sshd que rejeita a solicitação de encaminhamento de agente por falta de espaço no / tmp. Isso ocorreu porque o sshd precisa criar um soquete no / tmp. A limpeza do disco resolveu meu problema.

ssh -v disse então:

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device

— BartBiczBoży
fonte

11

Eu tive o mesmo problema, apenas as permissões estavam erradas em / tmp. OBRIGADO!!

— Nevyn

6

Outro motivo possível é o compartilhamento de conexão: um já pode estar conectado no outro host sem o encaminhamento do agente e o compartilhamento de conexão ativados. O segundo login com ssh -A(ou equivalente especificado no arquivo de configuração) através da conexão compartilhada ignorará silenciosamente o -Asinalizador. Somente após o logoff completo ou a desativação do compartilhamento de conexão para o segundo login, o encaminhamento do agente funcionará.

— W.Mann
fonte

2

Para o benefício de outros googlers que também chegaram a essa pergunta:

Espaço em branco incorreto em um arquivo ~ / .ssh / config também pode causar alguns arranhões na cabeça.

Recentemente, ajudei um dos meus colegas de trabalho que tinha isso:

# incorrect
host foobar ForwardAgent yes

em vez disso:

# correct
host foobar
  ForwardAgent yes

Também encontrei casos em que o recuo ausente das diretivas na lista de hosts fazia diferença na funcionalidade, mesmo que não devesse.

— Dale Anderson
fonte

0

Adicione as seguintes linhas ao arquivo .ssh / config

  Host **Server_Address**
     ForwardAgent yes

Adicionar chave ao agente SSH

 ssh-add -K

Conectar ao servidor remoto

ssh -v **username**@**Server_Address**

Executar teste de conexão no GitHub

ssh -T git@github.com

Execute o teste remoto ls no repositório git direcionado

git ls-remote --heads git@github.com:**account**/**repo**.git

— Tahsin Turkoz
fonte