¿Por qué no funciona el inicio de sesión automático a través de ssh con autorizado

12

He creado un dsa-keypair privado / público. He puesto la clave pública en el servidor en

~/.ssh/authorized_keys

Todo está configurado como mi otro servidor, pero parece que el servidor simplemente ignora mis esfuerzos.

security ssh login

— Magnar
fuente

Comprueba /etc/ssh/ssh_configy /etc/ssh/sshd_configpara verificar que nada de lo que deseas está desactivado.

— Kristopher Johnson el

También querrá verificar sshd_config.

— Vagnerr

Gracias. Actualicé la respuesta (que originalmente solo mencionaba ssh_config).

— Kristopher Johnson el

Todas las discusiones anteriores son perfectas si estás usando un estilo openssh de ssh. Si su sistema está usando ssh2, entonces tiene una forma totalmente diferente de administrar las claves. Este artículo trata sobre cómo y qué. burnz.wordpress.com/2007/12/14/…

— chris

1

Por lo general, verificar los /var/log/auth.logsistemas Debian o los /var/log/securede RedHat debería darle un consejo claro de lo que está mal configurado (por lo general, problemas de permisos)

— Giovanni Toraldo

15

Aunque su problema puede haber sido resuelto por otros respondedores, me he bloqueado de suficientes máquinas para no validar los cambios de sshd_config antes de cerrar la sesión, así que he encontrado el siguiente proceso que podría ser útil para la depuración futura de los cambios de configuración de sshd:

NO DESCONECTE una conexión ssh activa hasta DESPUÉS de que la prueba haya verificado que el comportamiento es el esperado.

a. verificar lo que crees que se supone que debe hacer

si. verificar que la configuración sea válida usando "-t"

C. iniciar una versión detallada de 'prueba' del servidor que puede monitorear en vivo

re. iniciar una conexión de cliente 'prueba' detallada que puede monitorear en vivo

a. verificar lo que crees que se supone que debe hacer

Revise el archivo de configuración sshd sin todos los comentarios con algo como lo siguiente (suponiendo que sshd_config sea el archivo correcto y en / etc / ssh)

$ grep -v "^ #" / etc / ssh / sshd_config | grep -v "^ $"

Esto simplemente aclara las cosas para que verifiquemos lo que creemos que estamos cambiando (no necesariamente si es correcto o no).

si. verificar que la configuración sea válida usando "-t"

Desde la página de manual de sshd's que estoy usando,

-t Modo de prueba. Solo verifique la validez del archivo de configuración y la cordura de las claves. Esto es útil para actualizar sshd de manera confiable ya que las opciones de configuración pueden cambiar.

Otros cambios pueden tener circunstancias más sutiles. Por ejemplo, no desactive la autenticación de contraseña hasta que esté seguro de que la autenticación de clave pública funciona correctamente.

C. iniciar una versión detallada de 'prueba' del servidor que puede monitorear en vivo

$ sudo / usr / sbin / sshd -ddd -p 9999

Esto mantiene activa su sesión de trabajo existente, pero le da otra instancia de sshd para verificar sus nuevos cambios de configuración. SSHD ahora se ejecuta en primer plano a un puerto definido por el usuario (9999 en nuestro ejemplo) y envía mucha información de depuración ruidosa que puede rastrear en / var / log / authlog (o posiblemente /var/log/auth.log dependiendo en su sistema operativo.)

re. iniciar una conexión de cliente 'prueba' detallada que puede monitorear en vivo

Ejecute la conexión del cliente ssh en modo detallado para mostrar en su pantalla más información que podría llevarlo a una mejor depuración de su error.

$ ssh -vvv -p 9999 nombre-servidor

Ahora debería tener suficiente información en los archivos de registro del servidor o en la pantalla de conexión del cliente para aislar su problema.

La solución generalmente se reduce a los permisos de archivo (como lo muestran Magnar y setatakahashi)

La mejor de las suertes

— samt
fuente

Supongo que también debe verificar el archivo ssh_config en el extremo del cliente para asegurarse de que está haciendo lo que espera. Use algo como lo siguiente para extraer comentarios:> grep -v "^ #" / etc / ssh / ssh_config | grep -v "^ $"

— sábado

Bueno, la configuración ssh del cliente se puede arreglar en cualquier momento, es el servidor del que se bloquea si lo configuró incorrectamente.

— Soviero

33

El servidor ignorará su archivo autorizado_claves si las propiedades del propietario son incorrectas. Cambiarlo a esto lo arregla:

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

— Magnar
fuente

66

ssh -vvv -l username server.domain le dirá si está enviando una clave válida

— Dave Cheney el

A veces he visto a sshd quejarse de malos permisos en el directorio de inicio, por lo que agrego "chmod o-rwx ~" (o al menos "chmod ow ~") a la lista como lo hizo setatakahashi. Esto generalmente se vuelve obvio cuando se monitorea el archivo de registro: los mensajes de error que he visto allí siempre apuntan en la dirección correcta.

— Olaf

Esta respuesta parece la más probable, pero el comentario de Dave Cheney es la única forma de ver lo que realmente está sucediendo. También verifique los registros del servidor.

— dwc

Este fue mi problema. Me golpeé la cabeza con esto durante horas. ¡Muchas gracias!

— Sam Soffes

1

Esto hizo el truco, pero mis permisos anteriores eran 0775y 0644respectivamente. ¿Por qué ayudó la reducción de los permisos? ¿Es esta una precaución de seguridad configurada en alguna parte?

— Dean

11

$ chmod 700 ~

$ chmod 700 ~ / .ssh

$ chmod 600 ~ / .ssh / Authorizedkeys

Verifique estos atributos en / etc / ssh / sshd_config

$ sudo grep Autenticación Pubkey / etc / ssh / sshd_config

Protocolo $ sudo grep / etc / ssh / sshd_config

— setatakahashi
fuente

2

Excelente punto sobre ~, debe asegurarse de que nadie que no sea usted puede escribir en el directorio inicial, de lo contrario podría cambiar el nombre de su archivo ~ / .ssh

— de Dave Cheney

ese último chmod debería ser: $ chmod 600 ~/.ssh/authorized_keysno$ chmod 600 ~/.sHh/authorized_keys

— SooDesuNe

3

lo que los valores de atributo deben ser ?

— Michael

0

Otra trampa importante ...

Si su directorio de inicio está encriptado, sshd no tendrá acceso a ~ / .ssh / optional_keys.

Ver esta respuesta

— A priori
fuente

¿Por qué no funciona el inicio de sesión automático a través de ssh con autorizado_claves?