Clave ssh aceptada por el host pero desconexión del cliente

Hola

Tengo un problema con SSH después de la instalación de fedora 23.

Cuando quiero conectarme a mi host remoto con clave privada, mi host encuentra la clave:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Pero como ves, mi cliente se desconecta por sí mismo

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Puedo conectarme a mi host con masilla en Windows usando la misma clave privada y puedo conectarme a mi teléfono usando una clave privada diferente.

Tiene alguna idea ?

/ etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Gracias

Editar: me puedo conectar con una contraseña

En primer lugar, hay numerosas documentaciones detalladas muy bien escritas sobre cómo configurar o configurar la autenticación basada en clave pública que están disponibles en línea. Eche un vistazo a uno de ellos y vea si ha seguido todo correctamente. Aquí hay uno. Así que no voy a repetir eso de nuevo.

El concepto muy básico es (copiado de aquí ):

La autenticación basada en claves utiliza dos claves, una clave "pública" que cualquiera puede ver y otra clave "privada" que solo el propietario puede ver. Para comunicarse de forma segura mediante la autenticación basada en claves, es necesario crear un par de claves, almacenar de forma segura la clave privada en la computadora desde la que desea iniciar sesión y almacenar la clave pública en la computadora en la que desea iniciar sesión.

Ahora desde el registro de depuración que ha publicado:

• Parece que hay dos usuarios diferentes involucrados. /home/theo/.ssh/authorized_keysy /home/tbouge/.ssh/id_rsa. ¿Está intentando iniciar sesión como un usuario en el directorio de inicio de otro usuario?
• El error Postponed publickey for theo..significa que se han intentado métodos de autenticación no deseados antes del método de clave de publicación. SSH probará todos los métodos de autenticación que estén habilitados en la configuración, uno tras otro. En su caso, ha GSSAPIAuthentication yeshabilitado lo que no está utilizando. Puede deshabilitarlo de forma segura haciendo GSSAPIAuthentication no.
• debug2: we did not send a packet, disable methodes muy probable que no pueda procesar el archivo de clave privada (ya sea un permiso de archivo o un problema de nombre). SSH es muy sensible sobre los permisos de directorios y archivos en computadoras locales y remotas. ( chown user_name:user_group -R /home/user` chmod 700 /home/.ssh` chmod 600 /home/.ssh/authorized_keys). Por lo tanto, asegúrese de que los suyos estén configurados correctamente. Vea esto: /unix/131886/ssh-public-key-wont-send-to-server

• En cuanto al tercer error: Permission denied (public key).hay un par de cosas para verificar.

  • Nombre de usuario incorrecto
  • Par de claves incorrecto

  • Anfitrión de destino incorrecto

    • Aquí hay más detalles: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance .

La siguiente parte es un poco confusa:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Para entenderlo mejor, veamos el proceso de autenticación paso a paso como se describe aquí en digitalocean :

1. El cliente comienza enviando una ID para el par de claves con el que desea autenticarse al servidor.
2. La comprobación del servidor es el archivo autorizado_claves de la cuenta en la que el cliente está intentando iniciar sesión para obtener la ID de la clave.
3. Si se encuentra una clave pública con ID coincidente en el archivo, el servidor genera un número aleatorio y utiliza la clave pública para cifrar el número.
4. El servidor envía al cliente este mensaje cifrado.
5. Si el cliente realmente tiene la clave privada asociada, podrá descifrar el mensaje usando esa clave, revelando el número original.
6. El cliente combina el número descifrado con la clave de sesión compartida que se utiliza para cifrar la comunicación y calcula el hash MD5 de este valor.
7. Luego, el cliente envía este hash MD5 al servidor como respuesta al mensaje de número cifrado.
8. El servidor utiliza la misma clave de sesión compartida y el número original que envió al cliente para calcular el valor MD5 por sí mismo. Compara su propio cálculo con el que envió el cliente. Si estos dos valores coinciden, demuestra que el cliente estaba en posesión de la clave privada y que el cliente está autenticado.

En su caso, como puede ver, la computadora remota solo aceptó su public key, cifró el paquete con esa clave y lo envió de vuelta a la computadora cliente. Ahora la computadora cliente necesita demostrar que tiene el derecho private key. Con solo la clave privada adecuada, puede descifrar el mensaje recibido y devolver una respuesta. En este caso, el cliente no puede hacer eso y el proceso de autenticación finaliza sin éxito.

Espero que esto le ayude a comprender los problemas y los resuelva.

¿Son correctos los privilegios en sus archivos ssh?

Carpeta .ssh -> 700

clave pública -> 644

clave privada -> 600

Verifique también usuario y grupo

Dices que tienes la misma clave en una máquina con Windows; ¿está seguro de que el archivo de clave privada que tiene en su máquina Linux es correcto? Tal vez la clave privada esté en un formato de masilla que ssh no entienda fácilmente. En cualquier caso, si pongo un archivo de clave privada incorrecto o no válido, obtengo exactamente el mismo error que usted tiene.

Para corregir el problema, sería más apropiado generar una nueva clave en la máquina Linux en lugar de reutilizar una clave de otra máquina. Simplemente puede agregar la nueva clave pública al archivo autorizado_claves en el host, y luego puede usar tanto la clave de Windows de Windows como la nueva clave de Linux de Fedora.

Su problema parece ser bastante común y claro, tengo que decir.

 Permission denied (publickey).

¿eso significa algo para ti? Para mí significa mucho para mí.

¿puede verificar en el lado del servidor si tiene selinux runnin en modo forzado por favor? si no, dime a qué modo se está ejecutando selinux.

Además, si puede hacer un intento más y capturar los registros de auditoría de ese intento y publicar aquí, definitivamente nos dirá por qué:

  tail -f /var/log/audit/audit.log  (and try to attempt)

Es un problema de permisos que está claro pero no un permiso de archivo :-)

Parece que el problema (en mi caso ...) fue causado por el tipo de clave.

Acabo de resolverlo agregando lo siguiente al ~/.ssh/configarchivo local (la máquina cliente Fedora 23):

PubkeyAcceptedKeyTypes=+ssh-dss

Aunque he agregado esa línea tanto al servidor como al archivo de configuración del cliente, solo el lado del cliente marcó la diferencia. Tenga en cuenta que los permisos deben ser 600para que se lea el archivo de configuración.

No sé si alguien más sigue teniendo este problema, pero finalmente lo resolví para mi única máquina (una computadora portátil) que estaba experimentando el problema. Yo creo que sé lo que eventualmente lo arreglaron, y dejaré la información aquí con la esperanza de que ayudará a cualquier otra persona que aún podría ser encontrarse con esto - y también para que alguien se espera que puedan comprobar mi solución y confirmar que es en realidad lo resuelve el problema.

Como resultado, el problema no era (para mí) con SSH en absoluto, sino con cómo PAM estaba configurando mis claves. La configuración /etc/pam.destaba desactualizada (aunque funcionaba correctamente a través de Fedora 22) y, como resultado, no se hicieron las cosas correctas en el inicio de sesión [más] para recoger mis claves $HOME/.ssh/. Ejecutando este comando:

# sudo authconfig --updateall

reconstruyó la configuración /etc/pam.d correctamente. En el siguiente reinicio, después de iniciar sesión, la primera vez que intenté ingresar a mi servidor, un cuadro de diálogo me pidió que ingrese mi frase de contraseña para mi clave ssh ( $HOME/.ssh/id_rsa). Lo hice, marqué la casilla "Desbloquear automáticamente al iniciar sesión" y ¡listo! Mi habilidad para salir de la computadora portátil fue restaurada.

Antecedentes

La pista que me llevó a resolver esto vino cuando importé una clave RSA de una fuente externa. (Una llave USB que llevo, con mi llave de "acceso remoto" para mi red doméstica. Apagué PasswordAuth en mi servidor externo hace años después de una intrusión.) Después de ssh-addpresionar ESA llave RSA, a diferencia de la que está instalada $HOME/.ssh/id_rsa, fue aceptado por el servidor remoto sin problema.

Luego terminé haciendo lo que debería haber sido redundante ssh-add, para recoger $HOME/.ssh/id_rsa. Noté que después de hacer eso, ssh-add -lcontenía dos entradas para la misma clave:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

Observe cómo una de las dos entradas no muestra el identificador de clave, solo el nombre de archivo de la clave privada que coincide con su firma pública. Como si la clave privada no estuviera realmente desbloqueada por el administrador del llavero.

Creo que eso es exactamente lo que estaba sucediendo, y PAM estaba pasando "claves malas" al agente SSH que no había sido desbloqueado con la frase de contraseña. Entonces, cuando ssh intentó autenticarse con la clave, en realidad no tenía la mitad privada (desbloqueada) del par de claves, por lo que la autenticación falló.

Ese último bit es una conjetura, pero independientemente de si alguien tiene problemas con las claves ssh que no son aceptadas por hosts remotos (donde solían estar) después de actualizar a F23, vale la pena intentar reconstruir el /etc/pam.d/directorio usando authconfigcomo solución.

Verifique los permisos del directorio de inicio del usuario. Es importante. Debe ser 755. 700 o 770 no funcionarán.

En su ssh_config, trate quitando los comentarios y / o añadir / eliminar / anexar a cualquiera de los Cipher, Cipherso MACslínea (s).

Me parece que sshdestá buscando un cifrado particular de algún tipo que no se incluye en la solicitud, que se puede agregar configurándolo en su ssh_config.

... y supongo que por casualidad no se ha PubkeyAuthenticationconfigurado noen el servidor remoto, porque eso definitivamente haría que esto fallara.