Ключ хоста ssh облачного сервера Google неожиданно изменился?
У меня есть облачный сервер Google, на котором сейчас работает Ubuntu 16.04. Я не делал для этого много лет, и он всегда отлично работал.
Так или иначе, сегодня он впервые испытал простой около 15 минут.
После перезапуска ssh выдает предупреждение «ВНИМАНИЕ: ИДЕНТИФИКАЦИЯ УДАЛЕННОГО ХОСТА ИЗМЕНИЛАСЬ!». Я уверен, что я, единственный администратор, не инициировал такие изменения. Последний раз я заходил в систему вчера.
Хотя я, очевидно, могу изменить файл известных хостов и приспособиться к новому ключу хоста, я очень обеспокоен этим изменением и подозреваю, что что-то не так. Кто-нибудь знает, почему происходит этот подсчет?
Я вошел в него из окна ssh облака Google, и, на первый взгляд, он работает как обычно, на моем веб-сайте. Однако прямо сейчас меня охватывает паранойя и что это может быть.
Спасибо!
То же самое случилось со мной сегодня (виртуальная машина Google Compute Cloud, работающая под управлением CentOS 7.x). После попытки войти в систему с компьютеров в разных сетях, vpns и т. Д. (Например, чтобы исключить возможность человека посередине на моей стороне) я в конце концов укусил пулю и вошел в одну из моих менее важных машин (которая использует другую закрытый ключ, чем мой prod server, но также был затронут той же проблемой).
Короче говоря, да, похоже, что некоторые виртуальные машины Google автоматически меняют свою собственную конфигурацию. В CentOS вы можете проверить /etc/yum/yum-cron.conf и, вероятно, увидите: apply_updates = yes
Затем также проверив ls -lh / etc / ssh, вы можете увидеть что-то вроде этого: 
Затем, наконец, проверив / var / log / messages, вы также можете увидеть доказательства автоматического обновления, влияющего на конфигурацию ssh:
Управление сменой ключей SSH было предметом обсуждения примерно с тех пор, как появился SSH. Вот один из нескольких вопросов по теме сбоя сервера: Ключ хоста SSH неожиданно меняется. Короче поменяли ключ, поменяли конфигурацию или кто-то делает что-то гадкое
Просмотрите журналы и свои резервные копии. Сравните предыдущие ключи с ключом сейчас, включая изменение типа ключа. Проверьте, были ли обновлены какие-либо пакеты SSH на сервере или клиенте. Найдите записи в файле журнала, например cloud-init который мог быть изменен, если изменилась идентификация виртуальной машины.
Осторожный вариант - перестроить чистый образ ОС с новыми ключами и учетными данными. Восстанавливайте данные приложения только из резервных копий. Эта работа может оказаться излишней. Однако это также может быть полезным упражнением по обеспечению непрерывности бизнеса, чтобы доказать, что вы можете отказаться от экземпляра, но сохранить свои данные.