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

Изменения идентификации хоста 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:

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

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

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