☰

No se puede conectar a través de SSH y clave pública y el usuario B (el usuario A puede)

tag-icon • tag-icon ssh login
No se puede conectar a través de SSH y clave pública y el usuario B (el usuario A puede)

SOLUCIONADO.Fue el bit de escritura del grupo en user_Bel directorio de inicio lo que me engañó.

Me estoy quedando sin ideas sobre este. Cualquier sugerencia sería muy apreciada.

Considere esta configuración:

  • Un servidor Sque ejecuta Ubuntu, usuarios boldewynyuser_Auser_B
  • Dos portátiles Ay B, cada uno con un usuario local boldewyn(tiene una id_rsaclave para iniciar sesión S) y una segunda clave id_rsa_A/ id_rsa_B. Todas las claves se almacenan en /home/boldewyn/.ssh. Ambos ejecutando Ubuntu.

  • user_Ay user_Bsi Stiene contraseñas vacías, el inicio de sesión solo debería ser posible mediante clave pública y SSH.

    +--------+            +-------------------+            +--------+
| laptop |            |       server      |            | laptop |
|   A    |            |         S         |            |   B    |
|        |            |                   |            |        |
+--------+    SSH     +-------------------+    SSH     +--------+
|id_rsa_A|------------|< user_A   user_B >|------------|id_rsa_B|
+--------+            +-------------------+            +--------+
|id_rsa  |------------|<    boldewyn     >|------------|id_rsa  |
+--------+            +-------------------+            +--------+

Que funciona:

  • Inicie sesión desde cualquier computadora portátil como boldewyn(usando id_rsayS:/home/boldewyn/.ssh/authorized_keys

  • Inicie sesión desde la computadora portátil Acomo usuario ( user_Ausando id_rsa_Ay S:/home/user_A/.ssh/authorized_keys:)ssh -i id_rsa_A user_A@S

Mi problema:En una computadora portátil, Bfalla exactamente la misma configuración user_B. No puedo iniciar sesión Sporque, por algún motivo, no se acepta la clave y aparece el mensaje de contraseña ( user_Bno tiene contraseña, esa no es una opción).

Lo que he comprobado:

  • En computadora portátil B:

    • Comprobados los derechos ~/.sshy todo su contenido.
    • poner parte pública de id_rsa_Bin boldewyns .authorized_keysy ssh -i id_rsa_B boldewyn@S: funciona (la clave no está corrupta o algo así)
    • ssh -vvv: Bueno, no es realmente útil: solo me dice en un momento que publickeyahora se salta el método. Ninguna razón dada.

  • En el servidor S:

    • Archivo user_Bs triplemente verificado.authorized_keys
    • Comprobado los derechos /home/*/.sshy todos sus contenidos (especialmente comparados user_Ay user_B)
    • Comprobado que $HOMEestá configurado (a través de sudo -u user_B -i)
    • Comprobado que todos los usuarios están en /etc/ssh/sshd_configs AllowUsers(y AllowGroups, por cierto)

Otras cosas:

La única diferencia que se me ocurre entre user_Ay user_Bes que creé este último con adduser -M(no cree un directorio de inicio; ya existía antes). Sin embargo, verifiqué tres veces que /home/user_Btodos los niños relevantes pertenecen a user_Bsu grupo principal.

Respuesta1

¿Lo comprobaste tres veces?/home/user_B(así como /home/user_B/.sshy /home/user_B/.ssh/authorized_keys) tenían los permisos adecuados:no se puede escribir excepto para el usuario, es decir, modo 755 o más restrictivo?

Respuesta2

Creo que podría estar relacionado con la forma en que generaste esas claves. Lo intentaría de nuevo. Las claves se generan con la función ssh-keygen. Quizás cuando se generó un conjunto de claves se utilizó una frase de contraseña en el proceso de generación. Puede intentar simplemente presionar la tecla Intro cuando se le solicite una frase de contraseña. Copie la parte de publicación de esa clave en ubuntu. Asegúrese de eliminar la entrada ofensiva en el archivo .ssh/authorized_keys. Un segundo pensamiento: si cat el archivo pub asegúrese de usar un >> (añadir) en lugar de > (reemplazar_ cuando copie el archivo pub al archivo autorizado_keys. (cat id_rsa.pub >> .ssh/authorized_keys).

Estoy un poco sorprendido. He usado mis métodos en el trabajo, usando Solaris y Cygwin, y en casa en mi Lan Linux compuesta por Centos, Slackware, Debian y Ubuntu. ¿Es posible que su clave privada no coincida con la pública? Cuando genera sus claves, obtiene un par, la pública se copiará tradicionalmente en el archivo .ssh/claves autorizadas en el directorio de inicio de la máquina de destino. Si vuelve a generar las claves, se debe copiar el nuevo archivo .pub. La nueva clave privada no se emparejará con la antigua pública. Noto que parece tener una carpeta .authorized_keys en el directorio de inicio. Nunca he probado eso. Creo que la ubicación normal es en la carpeta /home/user_name/.ssh/authorized_keys. Nunca he tenido problemas al usar ninguna versión de Solaris desde aproximadamente la 6 en adelante, Freebsd y varias iteraciones y versiones de Linux. Buena suerte

alan

información relacionada