ssh solicita una contraseña a pesar de .ssh / authorized_keys

ssh username@db2workgoup -n "echo cat ~ / .ssh / id_dsa.pub >> ~/.ssh/authorized_keys" y luego verifiqué que la key estaba almacenada en el file authorized_keys. Pero ssh sigue pidiendo la contraseña. Usé lo mismo para otros serveres dentro de nuestra compañía sin ningún problema.

¿Alguien puede ayudarme a ssh sin una request de contraseña?

  • ssh de OSX
  • ssh para abrir SUSE 11.2 (x86_64)
  • los permissions son para dir de inicio, .ssh dir y authorised_keys file 700 o less

/var/log/messages tiene la input ec 9 11:09:53 db2workgroup automount[3506]: update_negative_cache: key ".user.ini" not found in map. desde el momento en que traté de iniciar session

salida 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,rijndael-cbc@lysator.liu.se 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@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,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,rijndael-cbc@lysator.liu.se 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@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com debug2: kex_parse_kexinit: none,zlib@openssh.com 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: prefernetworking publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining prefernetworking: 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 prefernetworking: 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: 

Encontré la solución basada en el comentario de @jasonwryan en mi pregunta.

Había #AuthorizedKeysFile /usr/NX/home/nx/.ssh/authorized_keys2 en el file de configuration /etc/ssh/sshd_config sshd. Cambiar la input a AuthorizedKeysFile .ssh/authorized_keys estándar resolvió el problema.

En el pasado, encontré algunos tutoriales que describen cómo lograr una configuration ssh sin contraseña, pero algunos están tristemente mal.

Comencemos de nuevo y revisemos cada paso:

  1. DESDE CLIENTE – Generar key: ssh-keygen -t rsa

    • Las keys pública y privada ( id_rsa.pub e id_rsa ) se almacenarán automáticamente en el directory ~/.ssh/ .
    • La configuration será más fácil si usa una frase de contraseña vacía. Si no está dispuesto a hacer eso, entonces siga esta guía, pero también marque la viñeta a continuación.
  2. DESDE EL CLIENTE – Copie la key pública al server : ssh-copy-id user@server

    • La key pública del cliente se copyrá en la location del server ~/.ssh/authorized_keys .
  3. DESDE CLIENTE – Conéctese al server: ssh user@server

Ahora, si aún no funciona después de los 3 pasos descritos, intentemos lo siguiente:

  • Compruebe los permissions de la carpeta ~/ssh en el equipo del cliente y del server .
  • Compruebe /etc/ssh/sshd_config en el server para asegurarse de que las RSAAuthentication , PubkeyAuthentication y UsePAM no estén deshabilitadas, ya que están habilitadas de manera pnetworkingeterminada con yes .
  • Si ingresó una frase de contraseña al generar su key de cliente, puede probar ssh-agent y ssh-add para lograr conexiones sin contraseña en su session.
  • Compruebe el contenido de /var/log/auth.log en el server para encontrar el problema de por qué se omite la authentication de key.

También verifique la configuration 'AllowUsers' en / etc / ssh / sshd_config: Mine se configuró para permitir que solo un usuario inicie session, por lo que todos los demás estaban prohibidos, por lo que solicitó una contraseña (curiosamente, habría pensado que simplemente se rechazaría) acceso).

Si solo desea abrir una connection con otros hosts en la misma networking, entonces puede ser restrictivo y agregar un sufijo de subnetworking al nombre de usuario.

p.ej.,

AllowUsers adminusr localusr@192.168.9.0/24

permitirá el acceso a un usuario llamado 'localusr' en la subnetworking dada.