Autenticación del par de claves EC2

Autenticación del par de claves EC2

Creé una imagen ami ec2 personalizada e intenté autenticar la instancia de AWS mediante la autenticación del par de claves ec2 para un usuario USERVMsiguiendo los pasos a continuación.

  1. ami creación.
  2. instancias-ejecutar-ec2...
  3. cree una clave privada usando ec2-create-keypair.
  4. Clave privada almacenada en ~/.ssh/keypair.pem y permiso proporcionado.
  5. Conecte la instancia de AWS usandossh -v -i ~/.ssh/keypair.pem [email protected]

Registros de depuración correspondientes:

OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ec2-52-23-236-90.compute-1.amazonaws.com [52.23.236.90] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/keypair_14_10_721pm.pem type -1
debug1: identity file /root/.ssh/keypair_14_10_721pm.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY   
debug1: Server host key: ECDSA 12:6d:09:82:fd:4b:0d:1d:88:3d:2a:65:31:c0:ad:cd
The authenticity of host 'ec2-52-23-236-90.compute-1.amazonaws.com (52.23.236.90)' can't be established.
ECDSA key fingerprint is 12:6d:09:82:fd:4b:0d:1d:88:3d:2a:65:31:c0:ad:cd.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-52-23-236-90.compute-1.amazonaws.com,52.23.236.90' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/keypair_14_10_721pm.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
[email protected]'s password:
debug1: Authentication succeeded (password).
Authenticated to ec2-52-23-236-90.compute-1.amazonaws.com 

El sshd_config es el siguiente:

# Package generated configuration file
# See the sshd(8) manpage for details
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
#PermitRootLogin yes
PermitRootLogin without-password
StrictModes no
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
#IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
#PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
UseDNS no

El problema al que me enfrento es que la instancia de AWS solicita una contraseña cuando intento iniciar sesión con el usuario USERVM. La clave pública para el usuario USERVMse genera en el momento del arranque y se coloca en la instancia de AWS /home/USERVM/.ssh/authorized_keys. Sin embargo, el mismo enfoque para el usuario nombrado rootfunciona bien sin solicitar una contraseña. Cualquier ayuda aquí será agradecida.

Editar: Los permisos del usuario USERVMson:

$ sudo ls -la /home/
total 36
drwxr-xr-x  6 root       root      4096 Oct 14 12:34 .
drwxr-xr-x 27 root       root      4096 Oct 15 16:39 ..
drwxr-xr-x  2 admin      www-data  4096 Oct 14 12:34 admin
drwxr-xr-x  3 USERVM     www-data  4096 Oct 15 16:42 USERVM
drwx------  2 root       root     16384 Oct 14 12:38 lost+found
drwxrwsrwx 22 tuser      www-data  4096 Oct 15 16:40 tuser
$ sudo ls -la /home/USERVM/
total 16
drwxr-xr-x 3 USERVM  www-data 4096 Oct 15 16:42 .
drwxr-xr-x 6 root    root     4096 Oct 14 12:34 ..
-rw------- 1 USERVM  www-data  105 Oct 15 16:42 .bash_history
drwx------ 2 root    root     4096 Oct 15 16:38 .ssh
$ sudo ls -la /home/USERVM/.ssh/
total 12
drwx------ 2 root    root     4096 Oct 15 16:38 .
drwxr-xr-x 3 USERVM  www-data 4096 Oct 15 16:42 ..
-rw------- 1 root    root     1203 Oct 15 16:39 authorized_keys

Cuando intenta iniciar sesión con el mismo procedimiento para el usuario adminy USERVMle solicita la contraseña, sin embargo, rootfunciona sin solicitar la contraseña.

Respuesta1

Esperaba que este fuera el problema habitual de permisos en el archivo de claves autorizadas, pero es sutilmente diferente: elpropiedadTambién debe ser correcta, es decir, los archivos deben ser propiedad del usuario que los utiliza para autenticarse.

No creo que la propiedad del grupo importe tanto, porque los archivos y el directorio no deben poder escribirse en grupo, pero probablemente sea mejor configurarlos en el grupo principal del usuario.

En cualquier caso, cuando lo hiciste, chown -R USERVM:www-data ~USERVM/.sshel problema desapareció.

información relacionada