☰

Configurar nuevo usuario para AWS EC2 con SSH

tag-icon • tag-icon ubuntu ssh amazon-web-services
Configurar nuevo usuario para AWS EC2 con SSH

He creado una instancia EC2. Tiene conectividad a Internet y puedo acceder a ubuntu@ip usando 'test_kp.pem'.

Creé un nuevo usuario... useradd test-usery creé un nuevo par de claves test-user-kpen la consola de AWS EC2.

Creé el directorio home/test-user/.ssh y el archivo .ssh/authorized_keys

Ejecuté el comando ssh-keygen -f test-user-kp.pem -yy copié el contenido en claves_autorizadas. También arreglé los permisos de .ssh y el archivo autorizado_keys.

Ahora estoy intentando que ssh -i test-user-kp.pem test-user@ipel comando falle con el mensaje:

test-user@ip: Permiso denegado (clave pública).

Respuesta1

Hay algunas posibilidades para esto.

Al leer tu publicación, me pregunto si copiaste el contenido de test-user-pk.pem en ~ssh/authorized_keys. Si hiciste esto entonces ese es el problema. Ese archivo es la clave PRIVADA; la clave pública se encontrará en test-user-pk.pem.pub. Esto es bastante fácil de verificar porque el formato de la clave privada es bastante diferente al de la clave pública y comienza con --- --BEGIN OPENSSH PRIVATE KEY------ que abarca varias líneas, en lugar de una sola línea larga con 3 campos, probablemente comenzando con "ssh-rsa" y terminando con un nombre de usuario@nombre de host, con la clave pública en el medio.

De lo contrario -

En general, intente ingresar por ssh como el usuario con el indicador "-v" pasado a SSH para registrar lo que ve el cliente, y también busque en el archivo de registro del servidor mientras hace esto.

Puede llevar esto un paso más allá iniciando una segunda instancia de sshd en el servidor en un puerto alternativo y no desconectarla, y ver qué sucede cuando se intenta la conexión.

Algunas posibilidades específicas a considerar:

  • ¿SeLinux está rompiendo la instancia (es decir, permisos de archivos o similar)? He visto esto antes y es una molestia. El archivo audit.log indicaría si este es el caso y, si parece ser el caso, deshabilitar temporalmente selinux podría ayudar a descartar este problema. (He visto esto antes, pero no en las cajas de Ubuntu)

  • Hay algo en /etc/ssh/sshd_conf que impide la negociación, por ejemplo, una lista AllowUsers.

  • ¿Podría ser un problema de permisos con el directorio de inicio de los usuarios?

  • ¿Podría ser algo tonto, como que terminaste agregando la clave?

Respuesta2

Había creado 'claves_autorizadas' como root. Para solucionar esto corrí

sudo chown claves_autorizadas del usuario de prueba

información relacionada