☰

Аутентификация пары ключей EC2

tag-icon • tag-icon ssh amazon-ec2 amazon-web-services public-key
Аутентификация пары ключей EC2

Я создал собственный образ ami EC2 и пытаюсь аутентифицировать экземпляр AWS, используя аутентификацию пользователя с помощью пары ключей EC2, USERVMвыполнив следующие шаги.

  1. ами творение.
  2. ec2-run-instances ...
  3. создайте закрытый ключ с помощью ec2-create-keypair.
  4. Сохранил закрытый ключ в ~/.ssh/keypair.pem и предоставил разрешение.
  5. Подключите экземпляр aws с помощьюssh -v -i ~/.ssh/keypair.pem [email protected]

Соответствующие журналы отладки:

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

Конфигурация sshd_config выглядит следующим образом:

# 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

Проблема, с которой я столкнулся, заключается в том, что экземпляр aws запрашивает пароль при попытке входа с именем пользователя USERVM. Открытый ключ для пользователя USERVMгенерируется во время загрузки и помещается в экземпляр aws /home/USERVM/.ssh/authorized_keys. Однако тот же подход для пользователя с именем rootработает нормально, не запрашивая пароль. Любая помощь здесь приветствуется.

Редактировать: Разрешения для пользователя USERVM:

$ 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

При попытке входа в систему с использованием той же процедуры для пользователя adminсистема USERVMзапрашивает пароль, однако для rootпользователя система работает без запроса пароля.

решение1

Я ожидал, что это будет обычная проблема с разрешениями на файл авторизованных ключей, но это немного отличается:владениетакже должны быть корректными, т. е. файлы должны принадлежать пользователю, который использует их для аутентификации.

Я не думаю, что групповое владение имеет такое большое значение, поскольку файлы и каталоги не должны быть доступны для записи группе, но, вероятно, лучше всего назначить их основной группе пользователя.

В любом случае, когда вы это сделали, chown -R USERVM:www-data ~USERVM/.sshпроблема исчезла.

Связанный контент