ssh-copy-id no funciona

Estoy tratando de configurar un inicio de sesión SSH sin contraseña en CentOS 5.4:

1. Genere la clave pública RSA en el cliente.
2. ssh-copy-id del cliente al servidor.
3. Verificado ~ / .ssh / optional_keys contiene la clave del cliente.

El cliente todavía solicitó la contraseña. ¿Qué me perdí?

Gracias.

EDITAR: comprobó ssh_config y los permisos según lo recomendado. Esta es la información de depuración del cliente:

debug2: key: /home/saguna/.ssh/identity ((nil))
debug2: key: /home/saguna/.ssh/id_rsa (0x2b31921be9a0)
debug2: key: /home/saguna/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.1.75.
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/saguna/.ssh/identity
debug3: no such identity: /home/saguna/.ssh/identity
debug1: Offering public key: /home/saguna/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/saguna/.ssh/id_dsa
debug3: no such identity: /home/saguna/.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
[email protected]'s password: 

9/10 veces es porque ~ / .ssh / Authorized_keys no está en el modo correcto.

chmod 600 ~/.ssh/authorized_keys

Ingrese / etc / ssh / sshd_config para permitir la autenticación con una clave. Deberías tener algo como esto y asegurarte de que las líneas no estén comentadas:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

PD: no olvide reiniciar sshd después de modificar el archivo (/etc/init.d/sshd restart)

Descubrí que con mi sistema el problema era que el directorio de usuario (/ home / username) estaba equipado con los permisos incorrectos. Lo era drwxr-x-w-y tenía que serlo drwxr-xr-x(con permiso de escritura solo para el propietario). La solución fue usar chmod:

sudo chmod 0755 /home/username

No soy un experto aquí, pero también me encontré con ese problema, aquí están mis dos centavos además de todas las otras sugerencias.

A veces ssh-copy-idcopia la clave incorrecta en el servidor remoto (puede suceder si tiene varias claves y / o está utilizando nombres no predeterminados para los archivos de claves) o su agente de autenticación está mal configurado.

Aquí hay una cita de las páginas del manual :

Si se da la opción -i, se usa el archivo de identidad (predeterminado en ~ / .ssh / id_rsa.pub), independientemente de si hay claves en su agente ssh. De lo contrario, si esto: ssh-add -L proporciona algún resultado, lo usa con preferencia al archivo de identidad.

Entonces, básicamente, quieres comprobar eso:

• El agente de autenticación del sistema (generalmente ssh-agent) ve las claves que tiene la intención de usar (verifique la ssh-add -Lsalida)
  • Si no ve la clave deseada, agréguela usando ssh-add
• El ssh-copy-idcopiado la misma clave para el equipo remoto (solo iniciar sesión en el servidor remoto mediante contraseña y comprobar el contenido de ~/.ssh/authorized_keys)
  • Si no ve la clave deseada en el servidor remoto, puede decir implícitamente ssh-copy-idqué clave copiar:ssh-copy-id -i ~/.ssh/some_public_key

Espero que ayude.

El problema más común son los permisos no válidos en el lado del servidor. Verifique que ninguno de su directorio de inicio, ~/.sshy que ~/.ssh/authorized_keysnadie más que usted pueda escribirlos (en particular, no deben ser de escritura grupal).

Si ese no es el problema, corre ssh -vvv servery mira la vista del cliente sobre la conversación. En particular, verifique que el cliente esté probando la clave con el servidor.

Además de todo lo anterior, siempre se puede verificar el archivo de registro sshd:

/var/log/auth.log

Intenté las otras soluciones, pero descubrí que tenía que cambiar el directorio de inicio para que otros no pudieran escribirlo. El directorio de inicio era 777. Lo cambié a 755 y funcionó.

en mi caso / etc / ssh / sshd_config contenía el siguiente parámetro:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

Pero ssh-copy-id creó un archivo con el nombre certified_keys, así que tuve que modificar la entrada al nuevo nombre. Más información sobre las claves_desautorizadas2

Como complemento a la respuesta de Omer Dagan para el nuevo CentOS 7, use:

journalctl -f -u sshd

para mirar los registros sshd en el servidor.

El problema era que tenía la autenticación RSA desactivada en / etc / ssh / ssh_config