Как устроен ключ SSH: почему приватный ключ никуда не уходит

MAATRIX

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

Пара ключей: два файла, одна математическая связь

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

Правило простое и не имеет исключений: закрытый ключ (файл без расширения .pub, например id_ed25519) остаётся только на вашем компьютере и никогда никуда не копируется — ни на сервер, ни в облако, ни в переписку. Открытый ключ (id_ed25519.pub) для секретности не предназначен, его можно свободно передавать, публиковать и класть на любое количество серверов — зная его, ничего расшифровать или подделать нельзя.

Аналогия, которая обычно снимает путаницу: закрытый ключ — это ваша подпись, которую вы никому не отдаёте, но которой можете подписать документ. Открытый ключ — это образец подписи в паспортном столе, по которому любой может проверить, что подписали именно вы, но сам подписываться этим образцом не может. Сервер хранит только «образец» — открытый ключ, — и по нему проверяет подлинность, не имея возможности что-либо подписать от вашего имени.

Важно, что пара ключей никак не зависит от конкретного сервера. Один и тот же ключ можно предъявить хоть на десяти разных VPS — это не создаёт уязвимости, потому что на каждом сервере лежит лишь открытая половина, а закрытая как была, так и остаётся у вас одна.

Как сервер узнаёт вас, не видя закрытый ключ

Здесь и кроется суть, которая обычно вызывает вопросы: «а как сервер поймёт, что ключ мой, если я ему ничего не передаю?» Ответ — через криптографическую операцию, которую умеет выполнить только владелец закрытого ключа, а проверить результат может кто угодно с открытым ключом.

Упрощённо аутентификация по протоколу SSH (публично описана в RFC 4252) проходит так:

1. Клиент подключается и сообщает серверу, каким открытым ключом хочет представиться.
2. Сервер смотрит в ~/.ssh/authorized_keys и проверяет, есть ли там такой открытый ключ. Если нет — на этом всё, дальше даже пытаться не о чем.
3. Если ключ найден, серверу нужно убедиться, что клиент действительно владеет соответствующим закрытым ключом, а не просто подсмотрел чужой открытый. Формируется блок данных, привязанный к текущей сессии (включает случайный идентификатор сессии, чтобы ответ нельзя было записать и повторно использовать позже — это называется защитой от replay-атак).
4. Клиент подписывает этот блок своим закрытым ключом — то есть выполняет математическую операцию, которую можно сделать только зная закрытый ключ, — и отправляет обратно уже готовую подпись, а не сам ключ.
5. Сервер проверяет подпись открытым ключом из authorized_keys. Проверка подписи не требует знания закрытого ключа — это отдельная, «обратная» операция. Если подпись сходится, значит клиент владеет закрытым ключом, и доступ разрешён.

Раньше это часто объясняли через шифрование: сервер якобы шифрует случайные данные открытым ключом, а расшифровать их может только владелец закрытого ключа, доказывая тем самым владение им. Идея верна для классической асимметричной криптографии на RSA — зашифровать открытым ключом и расшифровать закрытым математически возможно, и старые схемы аутентификации так и работали. Современный протокол SSH-2 использует не шифрование, а цифровую подпись — операционно это другой процесс, но с тем же смыслом: подтвердить обладание закрытым ключом, не передавая его и не давая перехватчику ничего, что можно использовать повторно. Итог одинаковый в обоих случаях: закрытый ключ ни разу не покидает ваш компьютер, по сети идёт только результат операции над ним.

Отсюда прямое следствие: перехватить трафик SSH-сессии бесполезно для получения ключа — там просто нет закрытого ключа, который можно было бы украсть. Максимум, что видит наблюдатель — это подпись, действительную только для конкретной уже установленной сессии.

Ed25519 против RSA: в чём разница на практике

Оба алгоритма решают одну и ту же задачу — асимметричную пару «закрытый/открытый ключ», — но разной математикой, и с прямыми практическими следствиями.

На практике для нового сервера в 2026 году разумный выбор — ed25519: команда генерации короче, файл ключа компактнее, а сама схема EdDSA спроектирована с оглядкой на типичные ошибки реализаций RSA (например, слабые генераторы случайных чисел на некоторых устройствах в прошлом приводили к предсказуемым RSA-ключам). RSA остаётся в игре там, где нужна совместимость со старым оборудованием или ПО, не понимающим ed25519, — сетевые железки, старые дистрибутивы, некоторые корпоративные системы. Если сомневаетесь и не уверены, что все системы в цепочке поддержат ed25519, RSA с длиной 4096 бит — надёжный и универсальный запасной вариант.

Точные цифры производительности (сколько миллисекунд экономит ed25519 на подписи) сильно зависят от железа и версии OpenSSH, поэтому не буду приводить придуманные бенчмарки — на глаз разница на современном сервере не критична для одиночного входа по SSH, это скорее вопрос компактности ключа и качества исходной математики, чем скорости.

authorized_keys на сервере: что там на самом деле лежит

Файл ~/.ssh/authorized_keys — это простой текстовый файл, по одной строке на ключ. Никаких паролей, хэшей паролей или чего-то секретного там нет и быть не может — там лежат только открытые ключи, то есть та самая половина пары, которую не жалко потерять.

Строка выглядит примерно так:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGVub3VnaG9mYWtlZGF0YWZvcmV4YW1wbGVvbmx5 moy-noutbuk

Три части: тип ключа (ssh-ed25519 или, например, ssh-rsa), сама открытая ключевая строка в base64 и необязательный комментарий в конце (обычно имя пользователя@машины — просто ярлык для вашего удобства, на проверку не влияет). Если у вас несколько устройств — рабочий ноутбук, домашний компьютер, — вы просто дописываете в этот файл ещё одну строку с открытым ключом второго устройства. Сервер при подключении переберёт все строки и проверит, подходит ли подпись под какую-либо из них.

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

Обратная сторона: если кто-то получит доступ к серверу и допишет свой открытый ключ в ваш authorized_keys, он получит вход наравне с вами, и вы можете этого не заметить, если не проверяете файл. Поэтому периодическая проверка содержимого ~/.ssh/authorized_keys — разумная гигиена, особенно после того, как кто-то ещё имел root-доступ к серверу.

Генерация ключа на практике

Ключ создаётся на вашем компьютере, а не на сервере — генерировать его удалённо по SSH не только не нужно, но и противоречит самой идее: закрытая часть должна появляться и оставаться там, откуда вы будете подключаться.

ssh-keygen -t ed25519 -C "laptop-work"

Флаг -t задаёт тип ключа, -C — произвольный комментарий для удобной идентификации потом (когда ключей накопится несколько, вы не вспомните, какой из них с какой машины). Команда спросит путь для сохранения — по умолчанию ~/.ssh/id_ed25519 — и предложит задать passphrase, о которой ниже. В результате появятся два файла: id_ed25519 (закрытый, права должны быть 600, только для владельца) и id_ed25519.pub (открытый).

Если по какой-то причине нужен RSA, синтаксис аналогичен, только явно указывается длина ключа:

ssh-keygen -t rsa -b 4096 -C "laptop-work"

Меньше 4096 бит для новых RSA-ключей смысла настраивать нет — более короткие варианты исторически используются реже именно из соображений запаса прочности.

Дальше открытый ключ нужно перенести на сервер — вручную дописать содержимое .pub-файла в authorized_keys или воспользоваться утилитой, которая сделает это одной командой. Подробный пошаговый разбор этого шага, включая права доступа и отключение входа по паролю, — в статье про настройку SSH-ключей вместо пароля на VPS. Там же разобраны типичные грабли вроде неправильных прав на .ssh, из-за которых сервер молча отказывается принимать ключ.

Passphrase и ssh-agent: зачем защищать ключ, который и так не передаётся по сети

Логичный вопрос: если закрытый ключ и так никогда не покидает компьютер, зачем ещё и защищать его паролем (passphrase)? Ответ в том, что модель угроз тут другая: passphrase защищает не от перехвата по сети, а от кражи самого файла. Если ноутбук украдут, потеряют или на него проникнет вредоносное ПО и скопирует файл id_ed25519, без passphrase вор получает мгновенный доступ ко всем серверам, где стоит соответствующий открытый ключ. С passphrase у него на руках окажется бесполезный зашифрованный блоб, который ещё нужно расшифровать или подобрать к нему пароль.

Passphrase задаётся прямо при генерации (ssh-keygen спросит её сам) или добавляется позже:

ssh-keygen -p -f ~/.ssh/id_ed25519

Минус очевиден: если вводить passphrase при каждом подключении, часть удобства ключей теряется — вы просто заменили один пароль на другой, только на своей машине. Для этого существует ssh-agent — фоновый процесс, которому вы вводите passphrase один раз за сессию (например, при входе в систему), а дальше агент сам подписывает challenge от имени приложений, не спрашивая пароль повторно, пока сессия жива.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Первая команда запускает агент и настраивает переменные окружения, вторая — добавляет расшифрованный (в памяти агента, не на диске) ключ в его хранилище. Дальше ssh user@server использует ключ через агент прозрачно, без повторного ввода passphrase. Посмотреть, какие ключи сейчас загружены в агент, можно так:

ssh-add -l

На macOS и большинстве современных дистрибутивов Linux с графическим окружением ssh-agent обычно уже запущен и интегрирован с системной связкой ключей (Keychain, gnome-keyring), так что passphrase спрашивается один раз за вход в систему, а не за каждый терминал. Стоит отдельно упомянуть агентское перенаправление (ssh -A) — функцию, которая пробрасывает доступ к вашему локальному агенту на промежуточный сервер, чтобы с него подключаться дальше по цепочке своим же ключом. Удобно, но включать ForwardAgent стоит с осторожностью и только на серверах, которым вы доверяете: root на промежуточном сервере технически может воспользоваться проброшенным агентом, пока вы к нему подключены.

Что делать, если закрытый ключ всё же потерян (сгорел диск, украли ноутбук без passphrase) — отдельная тема, восстановить сам файл невозможно в принципе, и вопрос сводится к тому, как вернуть доступ к серверу другим способом. Это разобрано в статье про восстановление доступа при потере SSH-ключа.

Частые вопросы