☰

Не удается войти по SSH для экземпляров EC2, созданных из образа работающего EC2

tag-icon • tag-icon ssh amazon-ec2 ssh-keys amazon-ami
Не удается войти по SSH для экземпляров EC2, созданных из образа работающего EC2

У меня есть работающий экземпляр EC2 с несколькими пользователями, некоторые из которых имеют chroot в своих домашних каталогах, некоторые из них имеют только ftp и не имеют доступа к оболочке и т. д... ec2-user — это основная учетная запись администратора, хотя у других также есть доступ root и полный вход по ssh. На работающем экземпляре все работает отлично.

Я могу сделать снимок экземпляра и запустить новые экземпляры из снимка. Независимо от того, что я выберу в отношении пары ключей, связанной с новым экземпляром (использовать исходную пару ключей для ec2-user, создать новую пару ключей или не использовать пару ключей), после запуска и работы нового экземпляра я не смогу подключиться к серверу по ssh, используя ec2-user или любого другого пользователя с поддержкой ssh. Однако ftp работает нормально.

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

/var/log/secure попыток входа выдает мне:

sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method none
sshd[1739]: debug1: attempt 0 failures 0
sshd[1738]: debug1: user ec2-user does not match group list sftponly at line 142
sshd[1738]: debug1: PAM: initializing for "ec2-user"
sshd[1738]: debug1: PAM: setting PAM_RHOST to "..."
sshd[1738]: debug1: PAM: setting PAM_TTY to "ssh"
sshd[1739]: debug1: userauth-request for user ec2-user service ssh-connection method publickey
sshd[1739]: debug1: attempt 1 failures 0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: debug1: temporarily_use_uid: 500/500 (e=0/0)
sshd[1738]: debug1: trying public key file /etc/ssh/keys/ec2-user
sshd[1738]: debug1: restore_uid: 0/0
sshd[1738]: Failed publickey for ec2-user from xx.xx.xx.xx port 60597 ssh2
sshd[1739]: Connection closed by xx.xx.xx.xx 
sshd[1739]: debug1: do_cleanup

Это та же ошибка для всех пользователей с включенным ssh. Как вы можете видеть из журнала, я изменил свой sshd_config на исходном экземпляре так, чтобы он искал открытые ключи в папке /etc/ssh/keys.

Я смонтировал неисправные экземпляры как тома на работающем экземпляре. Ключи находятся в папке, с теми же разрешениями и теми же значениями ключей, все как и ожидалось. Вот ls -al папки ключей (.) и файл ec2-user.

drwxr-xr-x. 2 root     root     4096 Dec  1 16:59 .
-rw-------. 1 ec2-user ec2-user  388 Jul 25 13:27 ec2-user

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

ОБНОВЛЕНИЕ: Вот активные настройки в файле sshd_config:

#...
Protocol 2
#...
SyslogFacility AUTHPRIV
LogLevel DEBUG
#...
AuthorizedKeysFile /etc/ssh/keys/%u
#...
PasswordAuthentication no
#...
ChallengeResponseAuthentication no
#...
GSSAPIAuthentication yes
#...
GSSAPICleanupCredentials yes
#...
UsePAM yes
#...
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
#...
X11Forwarding yes
#...
Subsystem       sftp    internal-sftp -f AUTH -l VERBOSE
#...
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp -l VERBOSE -f AUTH
#...

решение1

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

Боюсь, у меня больше нет доступа к Redhat box, чтобы точно установить, каким должен быть контекст. Сказав это, попробуйте это:

ls -lZ /root/.ssh

Это даст контекст selinux, который нужен вашей новой папке. Если я правильно помню, это должно быть что-то вроде system_u:system_r:sshd_t

Затем нам необходимо применить этот контекст безопасности к новому расположению ваших авторизованных ключей:

semanage fcontext -a -t system_u:system_r:sshd_t “/etc/ssh/keys(/.*)?”

Который связал правильный контекст с новым расположением ключей. Наконец, мы можем применить контекст к новому расположению

restorecon -Rv /etc/ssh/keys

решение2

Установлена ​​ли директива 'AllowUsers' в sshd_config? Возможно, она установлена ​​для определенного пользователя на исходном сервере, а ssh еще не был перезапущен, поэтому он по-прежнему принимает всех пользователей?

О, я только что увидел это в отладке: «пользователь ec2-user не соответствует списку групп sftponly в строке 142». Проверьте sshd_config. Возможно, вы запретили группу или разрешили только sftp?

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