Como configurar ssh sem senha com chaves RSA

6

Estou tentando configurar uma configuração SSH sem senha entre duas máquinas e estou tendo um problema. Há uma tonelada de howtos por aí que eu segui e não tive sucesso. Aqui estão os passos que eu tomei

  1. Gere as chaves de autenticação no cliente. ( pressionado entrar quando solicitado por uma frase secreta ) [root@box1:.ssh/$] ssh-keygen -t rsa

  2. Copie a chave pública para o servidor. [root@box1:.ssh/$] scp id_rsa.pub root@box2:.ssh/authorized_keys

  3. Verificada a chave autorizada foi criada com sucesso no servidor

  4. Executou o seguinte comando: [root@box1:.ssh/$] ssh root@box2 ls

E eu ainda fui solicitado por uma senha. Eu li uma nota sobre um howto que dizia "dependendo da versão do SSH em execução ..." (embora não tenha especificado quais versões precisavam disso), pode ser necessário:

  • A chave pública em .ssh / authorized_keys2
  • Permissões de .ssh para 700
  • Permissões de .ssh / authorized_keys2 a 640

Eu também segui esses passos e não tive sucesso. Verifiquei que os diretórios home, root e .ssh não podem ser gravados por grupo (de acordo com o link ).

Alguém tem alguma ideia do que está perdendo?

Obrigado

EDIT: Eu também copiei a chave pública para a segunda caixa usando o comando ssh-copy-id e isso gerou o arquivo .ssh/authorized_keys .

[root@box1:.ssh/$] ssh-copy-id -i id_rsa.pub root@box2

EDIT2: incluindo informações sobre a versão

// box1 (as chaves do sistema foram geradas)

  • Linux 2.6.34
  • OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 de junho de 2010

// box2

  • Linux 2.6.33
  • Cliente Dropbear v0.52

EDIT3: saída de depuração

[root@box1:.ssh/$] ssh -vvv root@box2 ls
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to box2 [box2] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Not a RSA1 key file /root/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /root/.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 /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 dropbear_0.52
debug1: no match: dropbear_0.52
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-    
group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit:
[email protected],[email protected],ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-    
cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysatoe
debug2: kex_parse_kexinit:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-    
cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysatoe
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-    
sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-
sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-
cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit:
aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc,twofish256-cbc,twofish-
cbc,twofish128-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: hmac-sha1-96,hmac-sha1,hmac-md5
debug2: kex_parse_kexinit: zlib,[email protected],none
debug2: kex_parse_kexinit: zlib,[email protected],none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug2: dh_gen_key: priv key bits set: 132/256
debug2: bits set: 515/1024
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug3: check_host_in_hostfile: host 192.168.20.10 filename
/root/.ssh/known_hosts
debug3: check_host_in_hostfile: host 192.168.20.10 filename
/root/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 3
debug1: Host 'box2' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug2: bits set: 522/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/id_rsa (0x54b1c340)
debug2: key: /root/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred
gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

EDIT4: Outro desenvolvimento interessante. Ao invés de gerar as chaves na box1 (rodando o OpenSSH) e copiando elas para a box2 (rodando dropbear) eu fiz isso na ordem inversa:

[root@box2:.ssh/$] dropbearkey -t rsa -f id_rsa %código% [root@box2:.ssh/$] dropbearkey -y -f id_rsa | grep "^ssh-rsa" >> authorized_keys

E com isso eu sou capaz de emitir comandos sem senha de caixa2 para caixa1 SOMENTE se eu especificar o arquivo de ID: [root@box2:.ssh/$] scp authorized_keys root@box1:.ssh/

Ainda não é possível emitir comandos de box1 (OpenSSH) para box2 (dropbear).

    
por linsek 10.09.2012 / 18:03

4 respostas

8

Eu encontrei a fonte do problema. Houve uma mensagem vaga em /var/log/messages sobre a propriedade estranha que me deu a dica. Então, verifiquei e as permissões de /root , /root/.ssh e /root/.ssh/* estavam todas corretas (700), mas a propriedade era default.default . Não sei como isso aconteceu ... mas eu corri:

[root@box1:.ssh/$] chown root.root /root
[root@box1:.ssh/$] chown root.root /root/.ssh
[root@box1:.ssh/$] chown root.root /root/.ssh/* 

Para alterar a propriedade para login root e sem senha, funciona em ambas as direções.

    
por 13.09.2012 / 14:59
4

Este é um artigo muito simples, ao qual eu frequentemente volto, se não me lembro exatamente o que fazer com a configuração da chave SSH. É breve, mas completo e conciso.

link

    
por 17.09.2012 / 07:14
0

Você pode confirmar se o login root em ssh é permitido? keygen geralmente solicita senha. Você fez uma frase secreta enquanto keygen? Se sim, então está solicitando essa senha. Se você quiser acesso sem senha para conta sem cabeça, crie chaves privadas sem senha.

    
por 10.09.2012 / 19:40
-1

Na depuração: debug2: key_type_from_name: unknown key type '-----BEGIN' , parece que você tem um arquivo authorized_keys formatado incorretamente.
Remover as primeiras (duas?) Linhas, a última linha (----- End) e quaisquer outras quebras de linha devem corrigir o problema.

O arquivo-chave do Linux não usa o mesmo arquivo-chave de muitos geradores do Windows (e alguns do Linux). O PuTTY, por exemplo, inicia chaves privadas como ---- BEGIN SSH2 PUBLIC KEY ---- , mas o Linux está procurando por ssh-rsa AAAAB3NzaC1yc2E...G8HAaGz8ob6IXx3841ASs= Example@server A especificação completa pode ser encontrada aqui: link

Mas a versão curta é: * Nenhuma quebra de linha
* Começa com o protocolo (ssh-rsa, ssh-dsa)
* Chave pública
* Termina com "=" e o nome da chave

Deixe-me saber se isso ajuda

    
por 10.09.2012 / 21:46