Назад | Перейти на главную страницу

Ошибка входа в систему SSH для экземпляров EC2, созданных из образа рабочего EC2

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

Я могу сделать снимок экземпляра и запустить новые экземпляры из снимка. Независимо от того, что я выбираю с точки зрения пары ключей, связанной с новым экземпляром (используйте исходную пару ключей для пользователя ec2, создайте новую пару ключей или не используйте пару ключей), после запуска и запуска нового экземпляра я не могу ssh на сервер с помощью пользователя ec2 или любого другого пользователя с поддержкой 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.

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
#...

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

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

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

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

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