SSH usando ID incorreto

2

Eu estou tentando estabelecer ssh sem senha para mim mesmo em um sistema CentOS6. Eu faço os seguintes passos:

ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

Os arquivos de chave pública e privada apropriados, bem como as chaves autorizadas, são todos criados. O conteúdo de ~ / .ssh / id_dsa.pub é mostrado abaixo:

ssh-dss AAAAB3NzaC1kc3MAAACBAMtCKpsSeE8DxjvMqCl2S62YGmR/UMXpLH+tOuCiHzITUnB44kTBfh16WGRjAKdoFcrx/xIZBXyP5YTo1rIGzLbIK+LILOyaIe17mVYWgBs5k5WENLQKwQ3W0kaNvkN+uTcGArDl9r6o8oi8Lnox0ldCp/zGsNZuJfUnCOxX0PthAAAAFQD9wyrHwmyjMKWUhva+pwzhkYjbgQAAAIAqxFHO/Cb834Wa+PcNB80PvcPlwKHMrPnPZcEl+INsNmENU+khLe812GMD8GEsLbLxMgVKlFVAGXT0WUhCYpx7VTeawZ6/dOYlOf44Bjn2z6KAPkQaZyfTzF9gcunDdBY3uHJnOnj9c2bNfMPNc46D5cfPbAov/cNNnue2VWsmtwAAAIEAvJxL25YgbwJdwusIwcVMGjoFj8pRjYKFJwOLvfW1N+UI9u1ZCEkNmuRuOCSRgqDhL0Zr7qv11S8GT4sDdMat6xR7Qhw/Q3NwG4XIOJ5hGoHqlwIleE095JPQnmy8/ffn4qOYPql19RGwTM3lynGVIXBxcIEKzdmeoZKWG3ejS+I= [email protected]

No entanto, quando eu executo o comando "ssh computer.network.net" ou "ssh localhost", sou solicitado a fornecer uma senha (primeiro problema). Depois de inserir a senha e estabelecer a sessão ssh, eu saio e inspeciono o arquivo ~ / .ssh / known_hosts, onde a seguinte chave foi armazenada em cache:

localhost ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApHXsA7mMOtqKO1XotKTk5vM5F1LRoqxLLZw2TVLUA36BrkJAMM1EqfnH3mIoNz6sJzOdmQV2ubYGkzvCUb1TX8wUId1KQki8I1l2S52vFEwHkJlFe+KFQcU4SBtxDRDEvHkiLid0D37V+O3W6ElxhhRjkL+nebFPSFEdDlwBUTzAmR3KPD9zFjLP3JJZrwYH1E1sEl52pHbrcr7ROhfRjtz+3glVog9tJC3Xbfwu74JeywYrKQXbtDV84CJ0FoD6WAtJ+V0Dh8hnyBDkdbBc/zVIEDcXfcVNA4yc2noAHdQQ6p11Q8zW94/aJVhi/t0D9vSVMZP8UbHmnM2RfElIww==

que é uma chave RSA, não a chave DSA que eu gerenciei (segundo problema). Depois de fazer alguma escavação eu encontrei esta chave RSA em /etc/ssh/ssh_host_rsa_key.pub.

Por que o SSH está usando as chaves na pasta / etc / ssh e não as chaves que eu criei na pasta ~ / .ssh? Como posso dizer ao SSH para usar o par de chaves privadas públicas? a pasta ~ / .ssh. Uma olhada no homem ssh parece indicar que esse é o comportamento padrão, mas claramente não está acontecendo.

Obrigado antecipadamente.

UPDATE

A saída da tentativa de ssh -v localhost é detalhada, mas eu encontrei uma informação interessante:

debug1: Next authentication method: publickey
debug1: Offering public key: /home/admin-cloud/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
Agent admitted failure to sign using the key.
debug1: Trying private key: /home/admin-cloud/.ssh/identity
debug1: Trying private key: /home/admin-cloud/.ssh/id_rsa
debug1: Next authentication method: password

Então parece que ele encontra a minha chave ~ / .ssh / id_dsa, é aceita, e então vem o "Agente admitido falha ao assinar usando a chave". Depois disso, ele procura por ~ / .ssh / identity (não existe) e ~ / .ssh / id_rsa (não existe) e, finalmente, apenas pede uma senha. Alguma ideia sobre esse erro?

    
por JHowIX 27.08.2013 / 18:33

2 respostas

2

O arquivo authorized_keys deve conter a chave pública , e não a privada . O seguinte comando deveria ter usado o arquivo id_dsa.pub :

cat ~/.ssh/id_dsa >> ~/.ssh/authorized_keys

O arquivo known_hosts é para chaves de host, de modo que é o esperado.

Além disso, tente adicionar um ou mais flags -v ao executar ssh , ele imprimirá muitas informações úteis.

Editar: Você pode verificar quais chaves ssh-agent foram armazenadas em cache usando: ssh-add -L ?

Ou execute ssh-add (ou ssh-add ~ / .ssh / id_dsa ) para garantir que o arquivo no disco corresponda ao cache e tente novamente.

    
por 27.08.2013 / 19:20
1

Verifique o valor da sua variável de configuração IdentityFile em /etc/ssh/ssh_config e garanta que ela não seja substituída por ~/.ssh/config :

IdentityFile ~/.ssh/id_dsa

E, só para ter certeza (deve ser redundante, ssh-keygen cria com as permissões corretas), verifique se as permissões nesse arquivo são 0600 ou ssh não usará o arquivo.

Specifies a file from which the user's DSA, ECDSA or RSA authentication identity is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol version 2. Additionally, any identities represented by the authentication agent will be used for authentication. ssh(1) will try to load certificate information from the filename obtained by appending -cert.pub to the path of a specified IdentityFile.

The file name may use the tilde syntax to refer to a user's home directory or one of the following escape characters: ‘%d’ (local user's home directory), ‘%u’ (local user name), ‘%l’ (local host name), ‘%h’ (remote host name) or ‘%r’ (remote user name).

It is possible to have multiple identity files specified in configuration files; all these identities will be tried in sequence. Multiple IdentityFile directives will add to the list of identities tried (this behaviour differs from that of other configuration directives).

    
por 27.08.2013 / 19:47