ssh solicita senha apesar de .ssh / authorized_keys

5

Eu emiti ssh username@db2workgoup -n "echo cat ~ / .ssh / id_dsa.pub >> ~/.ssh/authorized_keys" e verifiquei que a chave estava armazenada no arquivo authorized_keys. Mas o ssh ainda está pedindo a senha. Eu usei o mesmo para outros servidores dentro da nossa empresa, sem quaisquer problemas.

Alguém pode me ajudar a ssh sem solicitação de senha?

  • ssh do OSX
  • ssh para openSUSE 11.2 (x86_64)
  • as permissões são para o diretório home, o diretório .ssh e o arquivo authorised_keys 700 ou menos

/var/log/messages tem entrada ec 9 11:09:53 db2workgroup automount[3506]: update_negative_cache: key ".user.ini" not found in map. desde o momento em que tentei fazer o login.

saída de ssh -vvv

radek:~ radek$ ssh -vvv root@db2workgroup
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to db2workgroup [10.0.0.22] port 22.
debug1: Connection established.
debug1: identity file /Users/radek/.ssh/identity type -1
debug1: identity file /Users/radek/.ssh/id_rsa type -1
debug3: Not a RSA1 key file /Users/radek/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/radek/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2
debug1: match: OpenSSH_5.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
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: 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,[email protected]
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,[email protected]
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-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: 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,[email protected]
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,[email protected]
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]
debug2: kex_parse_kexinit: none,[email protected]
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
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 133/256
debug2: bits set: 518/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /Users/radek/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 12
debug3: check_host_in_hostfile: filename /Users/radek/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 12
debug1: Host 'db2workgroup' is known and matches the RSA host key.
debug1: Found key in /Users/radek/.ssh/known_hosts:12
debug2: bits set: 509/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: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/radek/.ssh/identity (0x0)
debug2: key: /Users/radek/.ssh/id_rsa (0x0)
debug2: key: /Users/radek/.ssh/id_dsa (0x100123c50)
debug1: Authentications that can continue: publickey,keyboard-interactive
debug3: start over, passed a different list publickey,keyboard-interactive
debug3: preferred 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: Trying private key: /Users/radek/.ssh/identity
debug3: no such identity: /Users/radek/.ssh/identity
debug1: Trying private key: /Users/radek/.ssh/id_rsa
debug3: no such identity: /Users/radek/.ssh/id_rsa
debug1: Offering public key: /Users/radek/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: 
    
por Radek 09.12.2011 / 00:31

4 respostas

6

Eu encontrei a solução baseada no comentário @jasonwryan sob a minha pergunta.

Havia #AuthorizedKeysFile /usr/NX/home/nx/.ssh/authorized_keys2 no arquivo de configuração /etc/ssh/sshd_config sshd. Alterar a entrada para o padrão AuthorizedKeysFile .ssh/authorized_keys resolveu o problema.

    
por 09.12.2011 / 02:58
3

No passado, encontrei alguns tutoriais que descrevem como obter uma configuração sem senha ssh, mas alguns estão tristemente errados.

Vamos começar de novo e verificar todas as etapas:

  1. FROM CLIENT - Gerar chave: ssh-keygen -t rsa

    • A chave pública e privada ( id_rsa.pub e id_rsa ) será armazenada automaticamente no diretório ~/.ssh/ .
    • A configuração será mais fácil se você usar uma frase secreta vazia. Se você não estiver disposto a fazer isso, siga este guia, mas também verifique o ponto abaixo.
  2. FROM CLIENT - Copie a chave pública para servidor : ssh-copy-id user@server

    • A chave pública do cliente será copiada para a localização do servidor ~/.ssh/authorized_keys .

  3. FROM CLIENT - Conecte-se ao servidor: ssh user@server

Agora, se ainda não estiver funcionando depois dos três passos descritos, vamos tentar o seguinte:

  • Verifique as permissões da pasta ~/ssh na máquina cliente e servidor .
  • Verifique /etc/ssh/sshd_config no servidor para garantir que as opções RSAAuthentication , PubkeyAuthentication e UsePAM não estejam desabilitadas, pois elas estão ativadas por padrão com yes .
  • Se você inseriu uma frase secreta ao gerar sua chave de cliente, tente ssh-agent & ssh-add para obter conexões sem senha na sua sessão.
  • Verifique o conteúdo de /var/log/auth.log no servidor para descobrir o motivo pelo qual a autenticação de chave é ignorada.
por 19.03.2016 / 21:00
0

Verifique também a configuração de 'AllowUsers' em / etc / ssh / sshd_config: A mina foi configurada para permitir que apenas um usuário efetue login para que todos os outros sejam proibidos. Por isso, solicitou uma senha (estranhamente - teria pensado nisso apenas recusaria o acesso).

Se você quiser apenas abrir uma conexão com outros hosts na mesma rede, poderá ser restritivo e adicionar um sufixo de sub-rede ao nome de usuário.

por exemplo,

AllowUsers adminusr [email protected]/24

permitirá o acesso a um usuário chamado 'localusr' na subnet dada.

    
por 07.11.2017 / 07:48
0

Se você já fez todas as etapas, como gerar as chaves, colocar uma cópia no servidor, pode tentar executar ssh-add no seu local.

Além disso, você pode verificar a permissão dos arquivos de chave. No entanto, esse problema gera um tipo diferente de erro.

    
por 14.12.2017 / 09:47