Eu resolvi o problema simplesmente executando este comando na máquina local (depois de gerar a chave):
$ ssh-add
Estou trabalhando em centos6.5 (32 bits) e tentei efetuar login ssh sem senha usando ssh-keygen & ssh-copy-id? os passos que fiz:
primeiro criei a chave:
[root@dd ~]# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
/root/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
8f:48:0b:04:3a:e1:90:f4:9f:de:2a:33:63:ea:a8:82 [email protected]
The key's randomart image is:
+--[ RSA 2048]----+
|+o. |
|+o.. |
|o. .. |
| . .. . |
| .o. S |
| .o.o o |
|. .o.. . |
|E * . |
|*oo =. |
+-----------------+
copio a chave para o host remoto:
[root@dd ~]# ssh-copy-id -i /root/.ssh/id_rsa.pub 192.168.1.3
[email protected]'s password: My_Password
Now try logging into the machine, with "ssh '[email protected]'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
então eu tento fazer o login, mas ele falha (com chave):
[root@dd ~]# ssh 192.168.1.3
Agent admitted failure to sign using the key.
[email protected]'s password:
e como um registro detalhado:
[root@dd ~]# ssh -v [email protected]
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.3 [192.168.1.3] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/identity-cert type -1
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
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 '192.168.1.3' is known and matches the RSA host key.
debug1: Found key in /root/.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,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Unspecified GSS failure. Minor code may provide more information
debug1: Unspecified GSS failure. Minor code may provide more information
Cannot determine realm for numeric host address
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
Agent admitted failure to sign using the key.
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password:
Você estava sofrendo da seguinte falha:
Agent admitted failure to sign using the key.
Esta é uma mensagem infelizmente não diagnóstica. Existem (pelo menos) duas classes de problemas que podem ser abordados:
Para a maioria dos problemas, isso significa que seu ssh-agent não possui nenhuma chave ssh carregada que seja aceita para sua conta no servidor de destino. Nesse caso, conforme observado por @ Networker responda a esta questão, a solução é bastante simples: adicione a chave:
ssh-add
Se a chave estiver em um local não padrão, você precisará informar isso para ssh-add :
ssh-add /path/to/key
Este é o bug GNOME 754028 (entre outros e em Ubuntu ) : gnome-keyring e seahorse não podem criar nem adicionar novos tipos de chaves como ed25519 e chaves geradas com ssh-keygen -o -a 100 (como sugerido pelo Secure Secure Shell tutorial).
Diagnóstico deste problema:
ssh myserver falha com "falha admitida pelo agente ssh" SSH_AUTH_SOCK= ssh myserver funciona muito bem gnome-keyring não pode lidar com chaves complexas Como eu acabei de encontrar uma solução viável para este bug, e ele não parece ser publicado em lugar algum (exceto o comment Acabei de adicionar um bug do Ubuntu), vou colocar aqui.
Solução alternativa: inicie um novo ssh-agent usando o mesmo soquete que o de gnome-keyring :
ssh-agent -a $SSH_AUTH_SOCK
Isso inicia uma nova instância de ssh-agent (sobrescrevendo a instância menos capaz do GNOME), para que não tenha nenhuma chave (apesar do que seahorse diz, já que isso está ligado ao antigo agente). Você terá que adicioná-los via ssh-add conforme indicado na seção A chave não está carregada acima.
Você terá que executar isso toda vez que fizer login (ou adicioná-lo manualmente aos seus scripts de inicialização). Se você deseja preservar o soquete antigo, execute mv $SSH_AUTH_SOCK $SSH_AUTH_SOCK.broken primeiro.
Eu adicionei:
Host github.com
HostName github.com
User YOURUSERNAME
IdentityFile ~/.ssh/id_rsa.pub
ao meu arquivo ~ / .ssh / config para contornar este problema e parece estar funcionando.