Для экземпляров, недавно созданных AWS ECS, не настроен ssh authorized_keys

Мы используем Amazon Elastic Compute Services для развертывания кластера с группами автомасштабирования. До недавнего времени это работало нормально, и в целом все еще работает нормально ... За исключением того, что мы больше не можем подключаться к базовым экземплярам EC2, используя SSH с нашей парой ключей. Мы получаем ошибки с отказом в разрешении ssh, что относительно (недель) ново, и мы ничего не изменили. Напротив, мы можем запустить экземпляр EC2 напрямую и без проблем использовать SSH с той же парой ключей.

Что я сделал для расследования:

  1. Осушил кластер ECS, отсоединил от него экземпляр и остановил его.
  2. Отсоединил корневой том экземпляра и подключил его к другому экземпляру EC2.
  3. Заметил, что /home/ec2-user/.ssh не существует.
  4. В файле /var/log/cloud-init.log экземпляра обнаружена следующая ошибка:
Oct 30 23:23:09 cloud-init[3195]: handlers.py[DEBUG]: start: init-network/config-ssh: running config-ssh with frequency once-per-instance
Oct 30 23:23:09 cloud-init[3195]: util.py[DEBUG]: Writing to /var/lib/cloud/instances/i-0e13e9da194d2624a/sem/config_ssh - wb: [644] 20 bytes
Oct 30 23:23:09 cloud-init[3195]: helpers.py[DEBUG]: Running config-ssh using lock (<FileLock using file '/var/lib/cloud/instances/i-0e13e9da194d2624a/sem/config_ssh'>)
Oct 30 23:23:09 cloud-init[3195]: util.py[WARNING]: Applying ssh credentials failed!
Oct 30 23:23:09 cloud-init[3195]: util.py[DEBUG]: Applying ssh credentials failed!
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/cloudinit/config/cc_ssh.py", line 184, in handle
    ssh_util.DISABLE_USER_OPTS)
AttributeError: 'module' object has no attribute 'DISABLE_USER_OPTS'
Oct 30 23:23:09 cloud-init[3195]: handlers.py[DEBUG]: finish: init-network/config-ssh: SUCCESS: config-ssh ran successfully
  1. Изучил исходный код Python для /usr/lib/python2.7/site-packages/cloudinit. Мне это кажется нормальным; Я вижу ссылку в config / cc_ssh.py на ssh_util.DISABLE_USER_OPTS, и похоже, что ssh_util.py действительно содержит DISABLE_USER_OPTS в качестве переменной уровня файла. (Но я не профессиональный программист на Python, поэтому мне может не хватать чего-то тонкого.)
  2. Любопытно, что скомпилированные версии ssh_util.py и cc_ssh.py датируются 16 октября, что вызывает всевозможные красные флажки, потому что до недавнего времени мы не видели никаких проблем с ssh. Но я загрузил uncompyle6 и декомпилировал эти файлы, и декомпилированные версии кажутся тоже в порядке.

Глядя на cloud-init, довольно ясно, что если ссылка на ssh_util.DISABLE_USER_OPTS вызывает исключение, каталог .ssh не будет настроен для пользователя ec2, поэтому я понимаю, что происходит.

Я не понимаю почему? Кто-нибудь еще испытывал проблемы с cloud-init с недавно созданными экземплярами EC2 в ECS и нашел обходной путь?

Для справки, мы используем AMI amzn2-ami-ecs-hvm-2.0.20190815-x86_64-ebs (ami-0b16d80945b1a9c7d) в us-east-1, и мы определенно не видели этих проблем еще 15 августа. что некоторое изменение cloud-init, которое экземпляр получает через yum update, объясняет новое поведение и изменение дат записи скомпилированных модулей Python в cloud-init.

Я также должен добавить, что экземпляр EC2, который я создал для монтирования корневого тома экземпляра, созданного ECS, имеет несколько иной код cloud-init. В частности, модуль cc_ssh.py ссылается не на ssh_util.DISABLE_USER_OPTS, а на локальную DISABLE_ROOT_OPTS переменную. Так что все это подозрительно.


ssh amazon-web-services amazon-ecs cloud-init
person Eric Schoen    schedule 31.10.2019    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Я диагностировал эту проблему в конкретном развертывании AWS на AMI Amazon Linux2. Основная причина - запуск yum update, который вызывает обновление cloud-init из user_data, которое выполняется в cloud-init во время запуска экземпляра AWS EC2.

User_data, связанный с конфигурацией запуска ECS, выполняется cloud-init. Наш код инициализации user_data включал «yum update». Amazon развернул новую версию cloud-init, 18.5-2amzn2, которая еще не настроена в образах AMI (у них есть версия cloud-init 18.2-72-amzn2.07). Таким образом, обновление yum обновит cloud-init до версии 18.5-2amzn2. Однако анализ кода Python для версии 18.5-2amzn2 показывает, что он включает фиксацию (https://github.com/number5/cloud-init/commit/757247f9ff2df57e792e29d8656ac415364e914d), который добавляет атрибут ssh_util, отсутствующий в предыдущей версии. Обычно yum производит согласованную установку cloud-init, что подтверждается в автономном экземпляре EC2. Однако, поскольку обновление происходит в cloud-init, поскольку оно уже запущено, результаты несовместимы. Модуль ssh_util, по-видимому, не обновлен для запущенного cloud-init, поэтому он не может предоставить значение «DISABLE_USER_OPTS», которое было добавлено в вышеупомянутой фиксации.

person dmendres    schedule 31.10.2019
comment
Я думаю, ты справился. Если ssh_util уже был импортирован, а cc_ssh - нет, в работающем образе будут несовместимые модули. Более того, криминалистический анализ образа диска постфактум не выявит никаких проблем, статически на диске, потому что все будет выглядеть согласованно. Проблема могла возникнуть только в памяти процесса Python cloud-init. - person Eric Schoen; 31.10.2019

arrow_upward
2
arrow_downward

Итак, проблема действительно заключалась в команде yum-update, вызванной из cloud-init, которая обновляла сам cloud-init во время использования.

Я должен отметить, что мы использовали Amazon EFS на наших узлах и следовали точным инструкциям, которые Amazon указывает на своей странице справки для использования EFS с ECS, что включает вызов yum-update в скрипт пользовательских данных.

person Eric Schoen    schedule 01.11.2019