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

Tengo una instancia de una aplicación que se ejecuta en la nube en la instancia de Amazon EC2, y necesito conectarla desde mi Ubuntu local. Funciona bien en uno de ubuntu local y también en una computadora portátil. Recibí el mensaje "Permiso denegado (clave pública)" al intentar acceder a SSH a EC2 en otro Ubuntu local. Es muy extraño para mi.

Estoy pensando en algún tipo de problema con la configuración de seguridad en Amazon EC2, que tiene acceso limitado de IP a una instancia o un certificado puede necesitar regenerarse.

¿Alguien sabe alguna solución?

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

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

Como no se ha mencionado explícitamente, sshd es por defecto muy estricto en los permisos para los authorized_keysarchivos. Por lo tanto, si authorized_keysse puede escribir para alguien que no sea el usuario o si alguien que no sea el usuario puede hacerlo, 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 es escribible para otra persona que no sea el usuario, los usuarios autorizados a modificar esos directorios pueden comenzar a modificar los permisos de tal manera que puedan modificar / reemplazar 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 posee el .ssharchivo. Solucione esto a través de

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

Este tipo de problemas de permisos del sistema de archivos no se mostrarán ssh -vy ni siquiera se mostrará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 DEBUGallí en 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.
• Intenta autenticarte de nuevo.
• Averigüe dónde van los registros de su instalación de autenticación y léalos. (IIRC, /var/log/auth.logen distribuciones basadas en Debian; /var/log/secureen RHEL / CentOS / Scientific.)

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

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

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

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

Mi problema era que no estaba usando el usuario correcto. Al ejecutar el ssh con ubuntu @ ec2 ... funcionó de manera normal.

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 debe ejecutarse en el servidor al que intenta conectarse, mientras intenta conectarse. Mostrará errores en texto plano.

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 AllowGroups

Verifique su archivo / etc / ssh / sshd_config . Allí, encuentra la línea que dice

PasswordAuthentication no

Esa línea debe modificarse para decir sí en lugar de no. Además, reinicie el servidor sshd después.

sudo /etc/init.d/ssh restart

Quizás no sea relevante para el póster actual, pero podría ayudar a otros que encuentren esto al buscar respuestas a situaciones similares. En lugar de permitir que Amazon genere el par de claves ssh, le recomiendo cargar su propia clave ssh pública predeterminada estándar a Amazon y especificarla cuando ejecute una instancia EC2.

Esto le permite colocar la sintaxis de tipo "-i" en ssh, usar rsync con opciones estándar y también le permite usar la misma clave ssh en todas las regiones EC2.

Escribí un artículo sobre este proceso aquí:

Carga de claves ssh personales en Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

Curiosamente, mi problema resultó ser que el servidor se había reiniciado y se le emitió un nuevo nombre DNS. Estaba usando el antiguo nombre DNS. Sé que esto suena estúpido, pero me tomó un tiempo entenderlo.

Si estás intentando conectarte a un teléfono CyanogenMod con Dropbear, debes ejecutar las siguientes líneas para asegurarte de que todo funcione correctamente:

chmod 600 /data/dropbear/.ssh/authorized_keys

o

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

y

chmod 755 /data/dropbear/ /data/dropbear/.ssh

Esto me lo arregló, de lo contrario nada se puede conectar.

Si está utilizando CentOS 5, es posible que desee establecer StrictModes noen /etc/ssh/sshd_config. Estoy compartiendo el directorio / home usando NIS / NFS, y configuré todos los permisos correctamente, pero siempre me solicitó la contraseña. Después de configurar StrictModes no, el problema desapareció!

La respuesta de Greg explica cómo solucionar mejor los problemas, sin embargo, el problema real es que tiene una clave ssh configurada en un lado de la transacción (el cliente), que intenta la autenticación de clave pública en lugar de la autenticación basada en contraseña. Como no tiene la clave pública correspondiente en la instancia EC2, esto no funcionará.

Tuve el mismo problema, y ​​después de probar toneladas de soluciones que no funcionaron, abrí el puerto SSH en el firewall de mi enrutador (el panel de control del firewall de mi enrutador es un desastre, por lo que es difícil saber qué está pasando). De todos modos, eso lo solucionó :)

Súper sangriento y molesto que el error que obtienes es Permiso denegado, lo que implica que se hizo algún tipo de conexión, grr.

Tenía el mismo problema, aunque supuestamente seguía todos los pasos, incluidos

$ ec2-authorize default -p 22

Sin embargo, había comenzado mi instancia en la región us-west-1. Entonces, el comando anterior también debe especificar eso.

$ ec2-authorize default -p 22 --region us-west-1

Después de este comando, pude ingresar a la instancia. Pasé un rato antes de darme cuenta del problema y espero que esta publicación ayude a otros.

Este es un caso raro, pero si tiene habilitado selinux y está usando nfs para el directorio con las claves autorizadas (por ejemplo, directorios de inicio compartidos), deberá deshabilitar selinux (no recomendado por razones de seguridad, pero puede deshabilitarlo temporalmente) para ver si esto está causando el problema) o permitir que selinux use los directorios de inicio de nfs. No tengo claros los detalles, pero esto funcionó para mí. setsebool -P use_nfs_home_dirs 1

Acabo de experimentar el mismo problema después de agregar inadvertidamente permisos de escritura grupal al directorio de inicio de los usuarios.

Descubrí que esta era la causa al ejecutar tail -f /var/log/secureen la máquina y ver el error Authentication refused: bad ownership or modes for directory /home/<username>.