205 votos

¿Por qué obtengo un "Permiso denegado (clavepublica)" cuando se trata de SSH desde el local de Ubuntu a un Amazon EC2 servidor?

Tengo una instancia de una aplicación que se ejecuta en la nube, en la instancia de Amazon EC2, y necesito conectar desde mi Ubuntu. Funciona bien en uno de los locales de ubuntu y también portátil. Recibí el mensaje de "Permiso denegado (clavepublica)" cuando se trata de acceso SSH a EC2 en otro local de Ubuntu. Es tan extraño para mí.

Estoy pensando en algún tipo de problemas con la configuración de seguridad en el EC2 de Amazon, lo que ha limitado IPs de acceso a una instancia o certificado puede volver a generar.

¿Alguien sabe una solución?

136voto

graham.reeds Puntos9363

La primera cosa a hacer en esta situación es el uso de la -v opción ssh, así que usted puede ver qué tipos de autenticación que está probado y cuál es el resultado. ¿Que ayudan a iluminar la situación?

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

36voto

pkmk Puntos351

He recibido este error, porque se me olvidó agregar -l opción. Mi nombre de usuario local no fue la misma que en el sistema remoto.

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

16voto

Znarkus Puntos472

Algo que es más fácil de leer que ssh -i (en mi opinión, por supuesto), es tail -f /var/log/auth.log. Que se debe ejecutar en el servidor que está intentando conectarse, al intentar conectarse. Ella se muestran los errores en el texto.

Esto me ayudó a solucionar mi problema:

Usuario [nombre de usuario] de xx.yy.com no se permite debido a que ninguno de los grupos del usuario aparecen en AllowGroups

1voto

dF. Puntos29787

Como no ha sido explícitamente mencionado, sshd es por defecto muy estricta en los comandos para premissions en el authorized_keys archivos. Por lo tanto, si authorized_keys es modificable por cualquiera que no sea el usuario o puede ser hecho modificable por cualquiera que no sea el usuario, que va a negarse a autenticar (a menos que sshd está configurado con StrictModes no)

Lo que quiero decir con "se puede hacer de escritura" es que si alguno de los directorios padres son modificables para cualquiera que no sea el usuario, los usuarios autorizados a modificar los directorios pueden empezar a modificar los permisos de tal manera que se pueden modificar y reemplazar authorized_keys.

Este no se mostrará con ssh-v, que va a mostrar en los registros emitidos por sshd (normalmente en /var/log/secure o /var/log/auth.registro, depende de la distribución y configuración de syslogd).

De hombre sshd(8):

 ~/.ssh/authorized_keys
         Lists the public keys (RSA/DSA) that can be used for logging in
         as this user.  The format of this file is described above.  The
         content of the file is not highly sensitive, but the recommended
         permissions are read/write for the user, and not accessible by
         others.

         If this file, the ~/.ssh directory, or the user's home directory
         are writable by other users, then the file could be modified or
         replaced by unauthorized users.  In this case, sshd will not
         allow it to be used unless the StrictModes option has been set to
         "no".

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: