Кто на самом деле видит ваш пароль SSH в недоверенном VPN?

Проведите сеанс SSH через VPN, которым вы не управляете, и пароль всё равно принадлежит SSH-серверу, а не сети посередине. Если транспорт до проверенного хоста должным образом защищён, пассивный наблюдатель на этом пути не получает пароль в читаемом виде. Но измените одно условие, и ответ меняется: непроверенный хост, ослабленный список шифров или скомпрометированная рабочая станция дают разные результаты. Выполните проверки ниже по порядку и считайте каждую условием остановки.

Назовите получателя, прежде чем что-либо ввести

Поле пароля путешествует внутри сообщения аутентификации, а это сообщение путешествует внутри зашифрованного транспорта. Конфиденциальность — свойство транспорта, то есть она зависит от того, была ли согласована защита и была ли она согласована именно с тем хостом, который вы имели в виду. Именно эту вторую половину люди и пропускают. Соединение, зашифрованное до мошенника, одновременно конфиденциально и бесполезно. Вход в VPN ничего не доказывает о SSH-хосте, а репутация провайдера не заменяет проверку ключа.

Держите два направления раздельно в голове. Ключ хоста отвечает на вопрос, к какому серверу вы пришли. Аутентификация по паролю или ключу отвечает на вопрос, какого пользователя принимает сервер. Улучшение второго никогда не исправляет первое.

Проверьте идентичность хоста, запись и согласование

Начните на клиенте с записи, которая у вас уже есть. Опубликованный отпечаток, сверенный с доверенным источником, и запись в known_hosts, которая всё ещё совпадает, дают единственное доказательство, которое имеет значение до начала аутентификации.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

На стороне сервера выведите отпечатки, которые собираетесь публиковать, вместо того чтобы копировать их из памяти. Распространение их вне канала — в этом весь смысл; отпечаток, вставленный из того же чат-канала, что и имя хоста, доказывает только то, что оба пришли из одного места.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

Согласованные алгоритмы получаются из пересечения обеих сторон. Если конфигурация клиента закрепляет устаревший обмен ключами, чтобы добраться до старого устройства, этот выбор действует для каждого хоста, с которым он говорит, поэтому ограничьте его этим хостом, а не глобально.

Прочитайте методы, которые сервер действительно принимает

Знание того, какие методы аутентификации разрешает сервер, говорит вам, для чего вообще нужен пароль. У хоста, который принимает только открытые ключи, нет обмена паролями, который нужно защищать, а хост, который всё ещё принимает пароли, заслуживает осознанного решения, а не унаследованного значения по умолчанию.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Перевод пользователя на аутентификацию по ключу убирает пароль этого пользователя из того обмена. Это не делает скомпрометированную рабочую станцию безопасной и не делает недоверенный удалённый сеанс безвредным. Это разные риски с разными мерами. Решите также вопрос переадресации агента. Переадресация агента на недоверенный хост даёт этому хосту возможность использовать ваши ключи, пока длится сеанс, и это большее воздействие, чем вопрос о пароле, с которого всё началось.

Рассматривайте предупреждение о ключе хоста как шаг инцидента

Когда клиент предупреждает, что идентификация хоста изменилась, остановитесь и проверьте по каналу, который не проходит по тому же сетевому пути. Сравните отпечаток с консолью сервера или с оператором, который его перестроил. Удаление старой записи, чтобы заглушить предупреждение, — единственное действие, от которого нужно отказаться. Оно выбрасывает доказательство и превращает возможный перехват в обычный вход.

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

Чего этот регламент не охватывает

Оператор VPN, наблюдающий за трафиком, — это не то же самое, что программное обеспечение с локальными привилегиями на вашей машине. Компрометация конечной точки, враждебное расширение браузера или клавиатурный регистратор находятся ниже всего, о чём SSH может договориться, и никакой туннель этого не меняет. Если рабочая станция подозрительна, следуйте процедуре инцидента, а не проверяйте секретность, переподключаясь через другой выход. Переподключение доказывает, что сетевой путь изменился, и ничего — о конечной точке.

Завершите обычным случаем: проверенный хост, защищённый транспорт, намеренно выбранный метод аутентификации и никакой ненужной переадресации. Такое сочетание и есть ответ на вопрос в заголовке, и это четыре решения, а не одно.