История создания SSH: от telnet до OpenSSH

История SSH

История SSH началась с кражи паролей. До 1995 года удаленный вход на Unix-машину осуществлялся через telnet или rlogin, и оба этих протокола передавали пароль по сети в открытом виде. Любой, кто мог перехватить трафик, мог прочитать его, и к началу 1990-х годов это происходило повсеместно.

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

Что на самом деле передавали telnet и rlogin

Протокол Telnet определён в RFC 854, опубликованном в мае 1983 года Джоном Постелом и Джойс Рейнольдс. Он описывает терминальную сессию, передаваемую поверх TCP, и не содержит никакого шифрования. Каждый введённый вами байт, включая пароль, передаётся в открытом виде, и любое устройство на пути следования пакетов может его прочитать.

Протокол rlogin появился в составе Berkeley Unix и был описан позже в RFC 1282 (BSD Rlogin, Б. Кантор, декабрь 1991 года). Он добавил нечто более опасное, чем передача пароля в открытом виде: доверие на основе имени хоста. Сервер можно было настроить так, чтобы он принимал подключения с определённого хоста вообще без пароля. В RFC есть раздел под названием «Поучительная история» (A Cautionary Tale), в котором говорится: «Обход аутентификации по паролю для доверенных хостов открывает ВСЕ системы с такой конфигурацией, если хотя бы одна из них будет скомпрометирована». Также отмечается, что доверие привязано к именам хостов, поэтому компрометация DNS (domain name system) или подмена IP-адреса делают эту защиту бесполезной.

Обе архитектуры соответствовали сети, в которой они были созданы. Ранний Ethernet был общей средой: каждая машина в сегменте получала каждый кадр и должна была игнорировать те, что адресованы не ей. Машина, которая переставала их игнорировать (что и означает promiscuous mode), видела трафик всех остальных. Если добавить к этому университет, выдающий shell-аккаунты тысячам студентов, то один скомпрометированный аккаунт превращался в сборщик паролей для всего факультета.

Уведомление 1994 года, выпущенное без исправления

3 февраля 1994 года CERT опубликовал уведомление CA-94:01 под названием "Ongoing Network Monitoring Attacks". В нем сообщалось, что злоумышленники получили данные доступа к десяткам тысяч систем по всему интернету. Использованный ими инструмент переводил сетевой интерфейс в режим promiscuous mode и записывал начало каждого нового сеанса telnet, rlogin и FTP — именно ту часть, которая содержит имя пользователя и пароль.

CERT рекомендовал организациям сменить пароли для всех учетных записей, доступных по сети. Если сопоставить этот совет с особенностями протоколов, становится очевидна ловушка: новый пароль при первом же использовании передается по тому же каналу в открытом виде. Исправления для telnet или rlogin не существовало, так как ни один из этих протоколов не предусматривал механизмов для защиты данных.

Почему атака с перехватом трафика в Хельсинки привела к созданию SSH

В 1995 году сеть Хельсинкского технологического университета подверглась атаке с перехватом паролей, о которой ранее предупреждала организация CERT. Тату Илонен, работавший там исследователем, написал замену для существующих инструментов и в июле 1995 года выпустил её как бесплатное ПО. Он назвал его Secure Shell.

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

Распространению также способствовало то, что команды соответствовали тем, которые пользователи уже привыкли вводить. ssh заменил rsh и rlogin, а scp заменил rcp. Переход требовал лишь изменения привычки, а не рабочего процесса. К концу 1995 года база пользователей достигла примерно 20 000 человек в пятидесяти странах. В декабре того же года Илонен основал компанию SSH Communications Security для разработки и продажи этого программного обеспечения.

От бесплатного релиза к коммерческому продукту

По мере того как SSH становился бизнесом, лицензия на исходный код менялась. Более поздние релизы содержали условия, ограничивающие возможности использования кода другими лицами, и последним релизом, который можно было свободно использовать, стал ssh 1.2.12. В этом нет ничего предосудительного. Это просто означало, что версия SSH, на основе которой мог строить решения остальной мир, перестала развиваться, в то время как разработка продолжалась там, куда этот мир не имел доступа. Лицензии определяют, какой код выживет; это закономерность, о которой стоит прочитать в как лицензирование открытого ПО сформировало современную инфраструктуру.

Почему OpenBSD создала форк OpenSSH в 1999 году

В начале 1999 года Бьёрн Грёнвалль вернулся к последнему свободному релизу и начал исправлять в нем ошибки. Его версия называлась OSSH и поддерживала только протокол SSH 1.3.

Проект OpenBSD взял OSSH за основу и переработал его. Согласно собственным данным проекта, Тео де Раадт, Нильс Провос, Маркус Фридль, Боб Бек, Аарон Кэмпбелл и Даг Сонг выполнили работу по очистке, аудиту и расширению кода. Результатом стал OpenSSH 1.2.2, который вышел в составе OpenBSD 2.6 1 декабря 1999 года.

Почему форк, созданный небольшим проектом операционной системы, оказался почти на каждом компьютере? Из-за того, что требовалось OpenBSD. OpenBSD поставляет проверенную базовую систему, которая должна быть безопасной в конфигурации по умолчанию, поэтому зашифрованный удаленный вход в систему должен был находиться в этой базовой системе на условиях лицензии без каких-либо ограничений. Проверенный код под свободной лицензией — это именно то, что требовалось и всем остальным поставщикам операционных систем. Дэмиен Миллер, Филип Хэндс и другие почти сразу начали работу над портативной веткой, откуда и берется p в версиях вида 10.5p1. OpenBSD развивает чистую версию, а портативная ветка добавляет связующий код для всех остальных систем. То, как Unix разделился на системы, которые мы используем сегодня — это причина, по которой этот связующий код вообще необходим.

Поддержка второй версии протокола последовала позже. OpenSSH 2.0 вышел в составе OpenBSD 2.7 15 июня 2000 года.

Почему SSH-2 — это новый протокол, а не обновление версии

SSH-1 защищал целостность зашифрованного потока с помощью CRC-32 — контрольной суммы, предназначенной для обнаружения ошибок передачи, а не для противодействия злоумышленнику. В 1998 году Ариэль Футорански и Эмилиано Каргиеман из CORE SDI показали, к чему это приводит. При использовании режимов шифрования CBC или CFB и проверки CRC-32 злоумышленник, знающий хотя бы 16 байт открытого текста, может внедрить выбранный шифротекст, который получатель примет за подлинный. Это позволяет выполнять команды на сервере.

Уязвимость была заложена в самом протоколе, поэтому её нельзя было исправить без нарушения совместимости. Разработчики ПО внедрили детектор — код в файле deattack.c, который пытался распознать атаку в момент её совершения. В феврале 2001 года в самом детекторе обнаружили целочисленное переполнение (CVE-2001-0144), что привело к возможности удаленного выполнения кода на серверах и клиентах, где был установлен этот патч. Архитектура, которую невозможно исправить, обрастает патчами, а патчи приносят новые ошибки.

Протокол SSH-2 был разработан в рабочей группе IETF под названием secsh и опубликован в виде RFC в январе 2006 года: архитектура в RFC 4251, транспортный уровень в RFC 4253, аутентификация пользователя в RFC 4252, уровень соединений в RFC 4254. Разделение на уровни является ключевым моментом, так как каждый уровень теперь можно заменить независимо. Большая часть дальнейшей истории протокола — это процесс такой замены.

Два изменения заслуживают особого внимания. Проверка целостности была перенесена с CRC-32 на HMAC (код аутентификации сообщений на основе хеша), использующий общий секретный ключ. Теперь злоумышленник, не способный вычислить MAC, не может подделать пакет. Согласование ключей было переведено на алгоритм Диффи-Хеллмана. В SSH-1 клиент выбирал сессионный ключ и отправлял его, зашифровав открытым ключом RSA сервера. Поэтому любой, кто позже получал доступ к закрытым ключам сервера, мог расшифровать записанную сессию. Алгоритм Диффи-Хеллмана позволяет создавать уникальный секрет для каждой сессии, который никогда не передается по сети. Таким образом, запись трафика сегодня и кража ключа хоста в будущем не дают злоумышленнику никакой информации. Это свойство называется совершенной прямой секретностью (forward secrecy).

SSH-2 не имеет совместимости с SSH-1 на уровне передачи данных. Именно поэтому изменилась основная версия, а не дополнительная.

Почему протокол SSH-1 был удален, а не исправлен

Удаление заняло три релиза OpenSSH. В версии 7.0 от 11 августа 2015 года поддержка протокола 1 была отключена по умолчанию на этапе компиляции. В версии 7.4 от 19 декабря 2016 года была удалена серверная часть. В версии 7.6 от 3 октября 2017 года была удалена клиентская часть, включая соответствующие параметры конфигурации и документацию.

Сохранение поддержки в качестве опции для старого оборудования было бы более удобным решением, однако наличие детектора CRC-32 объясняет, почему от этого отказались. Переполнение было достижимо только потому, что код протокола 1 присутствовал в скомпилированном бинарном файле и находился в пути выполнения, который большинство администраторов считали неактивным. Код, который поставляется в составе ПО, может быть скомпрометирован. Удаленный код — нет.

Почему при первом SSH-подключении появляется предупреждение о ключе хоста

Шифрование гарантирует конфиденциальность трафика, но не подтверждает личность собеседника. Если злоумышленник находится на пути следования пакетов и отвечает вместо вашего сервера, вы получите полностью зашифрованную сессию с ним — это атака типа «человек посередине» (machine-in-the-middle). SSH решает эту проблему с помощью ключа хоста: сервер доказывает, что владеет закрытой частью пары ключей, а клиент сверяет этот ключ с тем, что был записан ранее. Если вас интересуют технические детали самого соединения, см. что происходит при открытии SSH-соединения.

При первом подключении истории нет, поэтому клиенту не с чем сравнивать ключ, и он вынужден спросить вас:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Ответ «yes» сохраняет этот ключ в ~/.ssh/known_hosts. Каждое последующее подключение будет сравнивать ключ с сохраненным значением, и при несовпадении программа выдаст самое тревожное сообщение из всех возможных:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Честная интерпретация этого первого запроса заключается в том, что протокол признает свой единственный уязвимый момент. Принцип «доверия при первом использовании» (Trust on first use) означает, что безопасность первого соединения зависит исключительно от безопасности сети, в которой вы находитесь. Этот пробел можно закрыть. Сверьте отпечаток ключа (fingerprint) через консоль провайдера или лог сборки сервера перед подключением. Опубликуйте его в DNS как запись SSHFP (RFC 4255), что имеет смысл только при наличии DNSSEC. Либо подписывайте ключи хостов собственным центром сертификации (CA), чтобы клиенты доверяли CA, а не каждому ключу в отдельности. На практике большинство пользователей принимают запрос без проверки, и об этом стоит говорить прямо.

Как открытые ключи вытеснили пароли

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

Вторая причина связана с арифметикой. Любой сервер с открытым портом 22 на публичном адресе круглосуточно получает автоматизированные попытки входа, а пароль представляет собой строку, которую можно подобрать. Криптографический ключ практически невозможно подобрать. Настройка PasswordAuthentication no полностью устраняет эту категорию атак, поэтому она присутствует в каждом контрольном списке по усилению защиты. Одновременно она отключает резервный способ входа, который раньше выручал при неисправности ключа. Поэтому заранее научитесь различать несколько неисправностей, которые сообщают об одной и той же ошибке Permission denied (publickey), чтобы однажды не заблокировать себе доступ. Отказ от паролей также означает накопление ключей. Если в агенте хранится десяток ключей, он предлагает их по очереди, пока сервер не достигнет лимита попыток и не разорвёт соединение. Поэтому вход может завершиться ошибкой Too many authentication failures, даже если правильный ключ загружен. Создание и ротация ключей описаны в разделе Основы управления SSH-ключами, а параметры на стороне сервера — в разделе Усиление защиты SSH на VPS.

Почему список алгоритмов SSH постоянно меняется

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

Алгоритм Ed25519 появился в OpenSSH 6.5 от 30 января 2014 года вместе с шифром chacha20-poly1305 и форматом закрытых ключей, защищенным с помощью bcrypt. Подписи Ed25519 формируют одноразовое число (nonce) для каждой подписи детерминированным способом, поэтому слабый генератор случайных чисел в момент подписи не может привести к утечке закрытого ключа. Именно так происходило восстановление закрытых ключей DSA и ECDSA в реальных инцидентах.

С DSA ситуация сложилась иначе. В 2015 году OpenSSH 7.0 отключил поддержку хостовых и пользовательских ключей ssh-dss во время выполнения, так как алгоритм ограничен 160-битным закрытым ключом и использованием SHA-1. Версия 9.8 от 1 июля 2024 года отключила DSA на этапе компиляции. Версия 10.0 от 9 апреля 2025 года удалила его, как выразились разработчики проекта, «завершив процесс устаревания, начатый в 2015 году». Десять лет от отключения до удаления.

RSA не исчез, но его старый формат подписи — да. OpenSSH 8.8 от 26 сентября 2021 года перестал принимать подписи RSA, созданные с помощью SHA-1, по умолчанию. В примечаниях к релизу причина указана прямо: SHA-1 криптографически скомпрометирован, а коллизии с выбранным префиксом можно было реализовать менее чем за 50 000 долларов США. Если вы когда-либо сталкивались с sign_and_send_pubkey: no mutual signature supported при подключении к старому серверу, это результат данного изменения. Ваш ключ в порядке. Алгоритм подписи, который запрашивает удаленная сторона, — нет.

Тот же процесс сейчас происходит с обменом ключами, на этот раз с опережением угрозы. Трафик, перехваченный сегодня, может быть сохранен и расшифрован спустя годы тем, кто первым получит доступ к мощному квантовому компьютеру, поэтому механизм согласования ключей должен был измениться до появления такой машины. OpenSSH 9.0 от 8 апреля 2022 года сделал гибридный обмен ключами стандартом: sntrup761x25519-sha512@openssh.com объединяет постквантовый алгоритм с обменом X25519, поэтому результат не слабее классической части, даже если новый алгоритм окажется неэффективным. OpenSSH 9.9 от 19 сентября 2024 года добавил mlkem768x25519-sha256, основанный на ML-KEM (module lattice key encapsulation mechanism), стандартизированном NIST в 2024 году. OpenSSH 10.0 сделал его стандартом для согласования ключей, а страница проекта о постквантовой криптографии разъясняет обоснование этого решения. OpenSSH 10.1 от 6 октября 2025 года начал выдавать предупреждение, если удаленная сторона не поддерживает этот механизм:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

Это предупреждение включено по умолчанию и управляется опцией WarnWeakCrypto в файле ssh_config. Что это означает на практике и что делать с сервером, который вызывает такое предупреждение, описано в разделе постквантовые стандарты обмена ключами SSH.

Что эта история означает для вашего сервера

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

Поэтому безопасность вашего SSH в основном определяется версией. Настройки по умолчанию содержат решения о том, какие алгоритмы предлагаются, какие отклоняются и какие предупреждения вы видите. Старый сервер продолжает предлагать всё, что было разрешено в его релизе, и будет понижать уровень безопасности при согласовании, чтобы соответствовать старому клиенту. По состоянию на август 2026 года текущим релизом является OpenSSH 10.5, выпущенный 11 августа 2026 года. Разрыв между ним и версией на машине, к которой никто не прикасался три года, — это и есть масштаб проблемы. Проверку этого стоит включить в первые десять минут работы с новым VPS.

FAQ

Кто создал SSH и зачем?

Тату Илонен, исследователь из Хельсинкского технологического университета, написал SSH в 1995 году после атаки с перехватом паролей в университетской сети. Инструменты удаленного доступа того времени, telnet и rlogin, передавали пароли по сети в открытом виде, поэтому любой, кто отслеживал общий сегмент сети, мог собрать учетные данные. Он выпустил программу как бесплатное ПО в июле 1995 года. К концу того же года у нее было около 20 000 пользователей в пятидесяти странах, а в декабре 1995 года он основал компанию SSH Communications Security.

В чем разница между SSH-1 и SSH-2?

Это разные протоколы, несовместимые на уровне передачи данных. SSH-1 был монолитным протоколом, который использовал CRC-32 для контроля целостности, а клиент отправлял сессионный ключ, зашифрованный RSA-ключами сервера. SSH-2 разделяет задачи на транспортный уровень, уровень аутентификации и уровень соединения (RFC 4251–4254, январь 2006 года), использует HMAC для контроля целостности и вычисляет сессионные ключи с помощью алгоритма Диффи-Хеллмана. Благодаря этому записанный трафик остается конфиденциальным, даже если ключ хоста будет скомпрометирован позже. Поддержка SSH-1 была удалена из OpenSSH поэтапно, окончательно — в версии 7.6 в октябре 2017 года.

Почему OpenSSH заменил оригинальную реализацию SSH?

Разработка оригинальной версии перешла в коммерческий продукт с ограничивающей лицензией, а последним свободно распространяемым релизом был ssh 1.2.12. В начале 1999 года Бьёрн Грёнвалл возродил этот релиз под названием OSSH, а команда OpenBSD создала форк OSSH под названием OpenSSH, который был включен в состав OpenBSD 2.6 от 1 декабря 1999 года. OpenBSD требовался проверенный код с неограниченной лицензией для базовой системы, и именно эти два свойства позволили всем остальным операционным системам использовать ту же реализацию через портативную ветку.

Почему SSH спрашивает о ключе хоста при первом подключении?

Потому что клиент никогда раньше не видел этот сервер и ему не с чем сравнивать ключ. Шифрование само по себе не может отличить честный сервер от машины, находящейся посередине пути (MITM), поэтому SSH идентифицирует серверы по ключу и записывает увиденное в ~/.ssh/known_hosts. Первое подключение — это единственный момент, когда нет сохраненного значения для проверки, поэтому клиент запрашивает подтверждение у вас. Сравните отпечаток ключа с тем, который вы получили через консоль провайдера или на самом сервере, и относитесь к любому последующему сообщению REMOTE HOST IDENTIFICATION HAS CHANGED как к реальному событию, пока не сможете объяснить его причину.

Почему старые SSH-ключи перестают работать после обновления?

Потому что OpenSSH выводит из эксплуатации алгоритмы согласно опубликованному графику. Ключи DSA (ssh-dss) были отключены по умолчанию в OpenSSH 7.0 в 2015 году и полностью удалены в OpenSSH 10.0 от 9 апреля 2025 года. Ключи RSA все еще работают, но подписи, созданные с помощью SHA-1, были отключены по умолчанию в OpenSSH 8.8 в сентябре 2021 года, что проявляется как sign_and_send_pubkey: no mutual signature supported при попытке подключения к старому серверу. Ключ Ed25519, доступный начиная с OpenSSH 6.5 с января 2014 года, позволяет избежать обеих проблем.