¿Por qué obtengo el permiso denegado (clave pública) cuando intento SSH desde Ubuntu local a un servidor Amazon EC2?

Solución 1:

Lo primero que debe hacer en esta situación es usar el -v opción a ssh , para que pueda ver qué tipos de autenticación se intentan y cuál es el resultado. ¿Ayuda eso a aclarar la situación?

En su actualización de su pregunta, menciona "en otro Ubuntu local". ¿Has copiado la clave privada ssh a la otra máquina?

Solución 2:

Como no se ha mencionado explícitamente, sshd es por defecto muy estricto con los permisos para el authorized_keys archivos Entonces, si authorized_keys es escribible para cualquier persona que no sea el usuario o se puede escribir por alguien que no sea el usuario, se negará a autenticarse (a menos que sshd esté configurado con StrictModes no )

Lo que quiero decir con "se puede hacer que se pueda escribir" es que si cualquiera de los directorios principales tiene permiso de escritura para alguien que no sea el usuario, los usuarios autorizados para modificar esos directorios pueden comenzar a modificar los permisos de tal manera que puedan modificar/reemplazar las claves_autorizadas.

Además, si el /home/username/.ssh El directorio no es propiedad del usuario y, por lo tanto, el usuario no tiene permisos para leer la clave, puede tener problemas:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Tenga en cuenta que Jane no posee el .ssh expediente. Solucionar esto mediante

chown -R jane:jane /home/jane/.ssh

Este tipo de problemas de permisos del sistema de archivos no aparecerán con ssh -v , y ni siquiera aparecerán en los registros de sshd (!) hasta que establezca el nivel de registro en DEPURAR.

• Editar /etc/ssh/sshd_config . Quieres una línea que diga LogLevel DEBUG ahí en alguna parte. Vuelva a cargar el servidor SSH utilizando el mecanismo proporcionado por la distribución. (service sshd reload en RHEL/CentOS/Scientific). Una recarga ordenada no eliminará las sesiones existentes.
• Intente autenticarse de nuevo.
• Averigüe dónde van los registros de su instalación de autenticación y léalos. (IIRC, /var/log/auth.log en distribuciones basadas en Debian; /var/log/secure en RHEL/CentOS/Scientific.)

Es mucho más fácil averiguar qué es lo que va mal con la salida de depuración que incluye errores de permisos del sistema de archivos. Recuerda revertir el cambio a /etc/ssh/sshd_config cuando haya terminado!

Solución 3:

Recibí este error porque olvidé agregar -l opción. Mi nombre de usuario local no era el mismo que en el sistema remoto.

Esto no responde a tu pregunta, pero llegué aquí buscando una respuesta a mi problema.

Solución 4:

Recibí este mensaje en una nueva instancia basada en la AMI de Ubuntu. Estaba usando la opción -i para proporcionar el PEM, pero aún mostraba el "Permiso denegado (clave pública)".

Mi problema era que no estaba usando el usuario correcto. Al ejecutar el ssh con [email protected] funcionó normalmente.

Solución 5:

Algo que es más fácil de leer que ssh -v (en mi opinión, por supuesto), es tail -f /var/log/auth.log . Eso debería ejecutarse en el servidor al que está tratando de conectarse, mientras intenta conectarse. Mostrará los errores en texto sin formato.

Esto me ayudó a resolver mi problema:

El usuario [nombre de usuario] de xx.yy.com no está permitido porque ninguno de los grupos de usuarios aparece en Permitir grupos