Идентификация хоста 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 поверх него? Должен ли я просто избегать его использования?

11
задан 18 November 2019 в 20:24
3 ответа

Или этот системные ключи хоста изменяются, или кто-то/что-то - MITM'ing соединение SSH.

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

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

21
ответ дан 2 December 2019 в 21:42

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

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

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

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

4
ответ дан 2 December 2019 в 21:42

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

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

18
ответ дан 2 December 2019 в 21:42

Теги

Похожие вопросы