Идентификация хоста SSH изменяется в одной беспроводной сети

Я регулярно подключаюсь через SSH к удаленному серверу из системы Ubuntu через порт по умолчанию 22. Давайте назовем сервер example.org, Я уверен, что этот сервер настроен правильно, и я подтвердил, что следующая проблема не зависит от моей ОС и сохраняется при повторной установке.

Существует одна конкретная точка доступа Wi-Fi, где, если я подключаюсь к серверу (ssh example.org) Я получаю это:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:[REDACTED].
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:3
  remove with:
  ssh-keygen -f "/home/user/.ssh/known_hosts" -R "serv.org"
ED25519 host key for serv.org has changed and you have requested strict checking.
Host key verification failed.

Проблемная точка доступа принадлежит академическому учреждению и кажется более закрытой, чем коммерческие сети интернет-провайдеров (например, я не могу загружать торренты по ней). Если я вернусь в другую сеть (скажем, используя свой телефон в качестве точки доступа), я смогу подключиться снова.

По словам Wireshark:

  • DNS-запрос (для 8.8.8.8) для example.org возвращает тот же IP-адрес, даже на проблемной точке доступа.
  • Обмен ключами SSH, кажется, происходит как обычно, но ключ, отправленный сервером в "Ответе обмена ключами ECDH", действительно имеет другой отпечаток, когда я подключаюсь через проблемную точку доступа.

Я не понимаю, что делает эта сеть. Блокировка порта 22 была бы одной вещью, но здесь я, кажется, добираюсь до сервера и получаю неправильный ключ как ответ.

Может ли эта точка доступа преднамеренно вмешиваться в соединение SSH? Есть ли способ для меня безопасно использовать SSH поверх него, несмотря на это? Должен ли я просто избегать его использования?

Источник

3 ответа

Решение

Либо ключи хоста этой системы меняются, либо кто-то / что-то MITM устанавливает SSH-соединение.

Надлежащий курс действий - считать этот хост скомпрометированным (хотя, скорее всего, это не сам хост, а соединение), если / пока у вас нет объяснения.

Вы можете обратиться к системному администратору этой точки доступа, сообщить им о своих проблемах и попытаться выяснить это с ними.

Источник

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

Пример такого брандмауэра: https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/decryption/decryption-concepts/ssh-proxy.html

Источник

Ответ Давидго правильный. Обратите внимание, что, пока вы используете аутентификацию pubkey, а не пароль, этот MITM не ставит под угрозу безопасность ваших учетных данных. Но это ставит под угрозу конфиденциальность и подлинность всего, что передается в течение сеанса. Обратите внимание, что "аутентичность всего, что передается через сеанс" включает (скорее, вероятно, полностью состоит из) команд, отправленных в оболочку, или любого другого процесса, с которым вы взаимодействуете, и вывод, отправленный обратно.

Первоначально я предложил следующее, что опасно неправильно, по крайней мере без дальнейших мер:

Один простой обходной путь - двойной SSH. Предполагая, что хост, на который вы входите, позволяет переадресацию портов, войдите один раз с нарушенным соединением, используя аутентификацию pubkey и с включенной переадресацией, чтобы переадресовать локальный порт на localhost:22например, -L 12345:localhost:22, Теперь вы можете запустить второй сеанс ssh, проходящий через первый туннель, и, если злоумышленник не ожидает, что вы это сделаете, этот второй сеанс будет иметь правильный отпечаток хоста, и вы знаете, что он действительно защищен и не подлежит перехвату со стороны MITM.

Это было написано на скорую руку как упрощение от правильного способа, которым я задумал сделать это, то есть иметь отдельную учетную запись, используемую исключительно для пересылки, без оболочки, которую, я считаю, по-прежнему безопасно использовать при взломе (MITM' г) соединение, но я бы все же посоветовал с осторожностью. Также возможно установить ваш authorized_keys файл для ограничения ключа, который вы используете для первоначального (MITM'd) входа в систему, так что он не может выдавать какие-либо команды, только пересылать соединения; если это так, такая установка должна быть безопасной.

Источник
Другие вопросы по тегам