☰

Permiso denegado (clave pública). SSH desde Ubuntu local al servidor Amazon EC2

tag-icon • tag-icon linux ssh amazon-ec2
Permiso denegado (clave pública). SSH desde Ubuntu local al servidor Amazon EC2

Tengo una instancia de una aplicación que se ejecuta en la nube en una instancia Amazon EC2 y necesito conectarme a ella desde mi Ubuntu local. Funciona bien en un ubuntu local y también en una computadora portátil. Recibí este mensaje Permission denied (publickey).al intentar realizar SSH a EC2 desde undiferenteUbuntu local.

Creo que puede haber problemas con la configuración de seguridad en Amazon EC2, que tiene acceso IP limitado a una instancia; o tal vez sea necesario regenerar un certificado.

¿Alguien conoce una solución al error de Permiso denegado?

Respuesta1

Lo primero que debe hacer en esta situación es utilizar la -vopción para ssh, así podrá ver qué tipos de autenticación se intentan y cuál es el resultado. ¿Eso ayuda a aclarar la situación?

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

Respuesta2

Como no se ha mencionado explícitamente, sshd es, por defecto, muy estricto en cuanto a los permisos de los authorized_keysarchivos. Entonces, si authorized_keysesgrabablepara cualquier persona que no sea el usuario ose puede hacer escribiblepor cualquier persona 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 alguno de los directorios principales se puede escribir para cualquier persona que no sea el usuario, los usuarios a los que se les permite 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/.sshdirectorio 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 es propietaria del .ssharchivo. Arreglar esto a través de

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 sshd (!) hasta que establezca el nivel de registro en DEBUG.

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

Es mucho más fácil descubrir qué está mal con la salida de depuración, que incluye errores de permisos del sistema de archivos. ¡Recuerde revertir el cambio cuando /etc/ssh/sshd_confighaya terminado!

Respuesta3

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

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

Respuesta4

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. Esto debe ejecutarse en el servidor al que intenta conectarse, mientras intenta conectarse. Mostrará 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 figura en AllowGroups

información relacionada