☰

Autenticação de par de chaves EC2

tag-icon • tag-icon ssh amazon-ec2 amazon-web-services public-key
Autenticação de par de chaves EC2

Criei uma imagem ec2 ami personalizada e tentei autenticar a instância aws usando a autenticação de par de chaves ec2 para um usuário USERVMseguindo as etapas abaixo.

  1. amei criação.
  2. ec2-run-instances ...
  3. crie uma chave privada usando ec2-create-keypair.
  4. Chave privada armazenada em ~/.ssh/keypair.pem e fornecida permissão.
  5. Conecte a instância do AWS usandossh -v -i ~/.ssh/keypair.pem [email protected]

Logs de depuração correspondentes:

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

O sshd_config é o seguinte:

# 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

O problema que estou enfrentando, a instância do AWS pede senha quando tenta fazer login com o usuário USERVM. A chave pública do usuário USERVMé gerada no momento da inicialização e colocada na instância aws /home/USERVM/.ssh/authorized_keys. No entanto, a mesma abordagem para o usuário nomeado rootfunciona bem sem solicitar senha. Qualquer ajuda aqui é apreciada.

Editar: as permissões do usuário USERVMsão:

$ 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

Ao tentar fazer o login com o mesmo procedimento para o usuário admin& USERVMele pede senha, porém para rootfuncionar sem pedir senha.

Responder1

Eu esperava que esse fosse o problema usual de permissões no arquivo de chaves autorizadas, mas é sutilmente diferente: opropriedadetambém devem estar corretos, ou seja, os arquivos devem pertencer ao usuário que os utiliza para autenticação.

Não acho que a propriedade do grupo seja tão importante, porque os arquivos e o diretório não devem ser graváveis ​​em grupo, mas provavelmente é melhor configurá-los para o grupo principal do usuário.

De qualquer forma, quando você fez isso, chown -R USERVM:www-data ~USERVM/.ssho problema desapareceu.

informação relacionada