SSH-ключи: объяснение
Аутентификация по ключу SSH — это способ войти на сервер без пароля: вместо того чтобы вводить секрет, который сервер может проверить, ваш компьютер доказывает, что владеет закрытым ключом, подписывая вызов, который посылает сервер, а сервер проверяет подпись по открытому ключу, который у него уже есть в архиве. Закрытый ключ никогда не пересекает сеть, поэтому нечего перехватывать, нечего выманивать фишингом и нечего угадывать. В этой статье объясняется, как работают две половины пары ключей, какой тип ключа выбрать в 2026 году, как отпечатки останавливают посредника при первом подключении, как содержать authorized_keys и known_hosts в чистоте и что именно делать при утечке ключа. Чтобы создать, проверить или конвертировать ключ в браузере, используйте набор ключей SSH, а чтобы проверить пароли, которые вы ещё используете, — проверку утечки паролей.
Что такое аутентификация по ключу SSH
Каждый вход — это вопрос, который задаёт сервер: вы тот, за кого себя выдаёте? — а пароль отвечает на него, передавая сам секрет. В этом слабость всей схемы: секрет путешествует, его можно подслушать, его можно воспроизвести, и его можно угадывать, попытка за попыткой, пока он не падёт. Аутентификация по ключу SSH меняет ответ. Вместо отправки секрета ваш компьютер подписывает случайный вызов сервера закрытым ключом, который никогда не покидает ваш компьютер, а сервер проверяет подпись по открытому ключу, хранящемуся в вашем файле authorized_keys. Доказательство каждый раз свежее, потому что вызов случаен; секрет никогда не появляется в проводе, поэтому слушатель не узнаёт ничего, что можно повторно использовать, и угадывать пароль не нужно, потому что пароля вообще нет.
Идея старше современного интернета — криптография с открытым ключом восходит к 1970-м годам — но именно SSH сделал её повседневным способом попасть на сервер, и протокол несёт её с тех пор. Когда вы выполняете ssh пользователь@сервер, клиент и сервер договариваются о сеансе, сервер предъявляет вызов, привязанный к вашей учётной записи, а ваш SSH-агент подписывает его закрытым ключом, обычно после того, как вы один раз разблокировали ключ парольной фразой. Если подпись проверена, вы внутри. Ничто в обмене не зависит от общего секрета, который знает и сервер, поэтому взлом сервера не раскрывает ваши учётные данные: сервер хранит только открытые ключи, а открытый ключ бесполезен для входа. Эта асимметрия — сервер может проверить, но не может выдать себя за вас — и есть весь аргумент безопасности ключей, а также причина, по которой потеря контроля над закрытой половиной — единственный провал, который имеет значение.
Открытый ключ и закрытый ключ
Пара ключей — это две половины с противоположными правилами, и большинство ошибок SSH происходят из-за того, что с ними обращаются одинаково. Открытый ключ создан, чтобы его копировали повсюду: вставляйте его в authorized_keys на каждом сервере, которым вы пользуетесь, в вашу учётную запись Git-хостинга, в любой сервис, принимающий SSH-ключи. Его можно опубликовать в открытом репозитории, напечатать на слайде или отправить администратору по почте, потому что всё, что он позволяет кому-либо, — это проверить подпись. Знание вашего открытого ключа не даёт злоумышленнику ничего для входа, так же как знание номера вашего дома не даёт никому ключ от вашей входной двери. Открытая половина — это замок, а не ключ, а замки созданы, чтобы их было видно.
Закрытый ключ — это сам ключ, и его правило прямо противоположное: он никогда не покидает ваш компьютер, только вы можете его читать, и его нельзя вставлять в чат, тикет, письмо, сообщение на форуме или общий документ — даже чтобы спросить, безопасен ли он. Тот, у кого он есть, может войти от вашего имени на каждый сервер, доверяющий соответствующему открытому ключу, без запроса пароля и без второго фактора на пути, если вы его не настроили. На диске он живёт в ~/.ssh, защищённый правами на файл — chmod 600, только владелец может читать и записывать — и в идеале парольной фразой, которая шифрует файл, так что украденная копия остаётся бесполезной без слов, которые её разблокируют. Парольная фраза — не часть ключа; это навесной замок на коробке, в которой лежит ключ. Потеряете коробку — и замок останется единственной преградой между вором и вашими серверами, поэтому закрытый ключ без парольной фразы никогда не должен покидать компьютер, который вы полностью контролируете.
Ed25519 против ECDSA и RSA: что выбрать в 2026 году
В 2026 году ответ по умолчанию — Ed25519, и это же значение по умолчанию генерирует этот сайт. Ed25519 — это 256-битный ключ на эллиптической кривой: он создаётся за долю секунды, быстро подписывает и даёт открытый ключ, умещающийся в одну короткую строку. Он поддерживается OpenSSH с 2014 года и всеми современными серверами и клиентами, а его безопасность опирается на кривую, спроектированную открыто, без подозрительных констант. Нет практической причины выбирать что-то другое для нового ключа, если только что-то в вашем окружении не заставляет вас. Если вы вынесете из этой статьи одну рекомендацию, пусть это будет она: создайте Ed25519, задайте парольную фразу и двигайтесь дальше.
Другие типы существуют для исключений. ECDSA на кривых NIST P-256 или P-384 — правильный выбор там, где политика требует кривых NIST: некоторые регулируемые среды и старые аппаратные токены их предписывают, — и это надёжный запасной вариант, если браузер или устройство не может создать Ed25519. RSA остаётся универсальным запасным вариантом: RSA 2048 — минимум, который стоит использовать, RSA 3072 или 4096 — выбор, когда другая сторона вообще не умеет работать с эллиптическими кривыми, что сегодня означает в основном очень старые системы и несколько встроенных устройств. Всё ниже RSA 2048 — RSA 1024, DSA, ssh-dss — это наследие, и его следует вывести из употребления: набор ключей SSH помечает его как слабое именно по этой причине. Однако размер ключа — не всё: 4096-битный ключ RSA, скопированный на ноутбук, которым вы больше не владеете, хуже 256-битного ключа Ed25519, который хранится как следует, потому что режим отказа SSH-ключей почти никогда не связан с математикой. Он связан с файлом.
Отпечатки и первое подключение
При первом подключении к серверу SSH показывает вам нечто, похожее на случайную строку символов, и спрашивает, доверяете ли вы ей: 256 SHA256:M8zvXkwyrGfPUmaHSSdA1aFQkH8AVSRycOxaZHru7dQ. Эта строка — отпечаток ключа хоста сервера, хэш открытого ключа сервера, — и это единственное, что стоит между вами и посредником. Если отпечаток совпадает с опубликованным вашим администратором или с тем, который вы проверили по отдельному каналу, то отвечающая машина действительно является тем сервером, к которому вы хотели попасть. Если не совпадает, остановитесь: кто-то может перехватывать соединение, или сервер мог быть пересобран с новым ключом, и в любом случае безопасный шаг — проверить, прежде чем вводить yes. Этот запрос — SSH за своей самой важной работой, а в беду попадают те, кто приучил себя вводить yes, не читая его.
Вы можете проверить отпечаток ещё до подключения с помощью ssh-keygen -lf, который печатает по одной строке на ключ: размер в битах, отпечаток, комментарий и тип ключа в скобках, например 256 SHA256:… пользователь@пример.com (ED25519). Набор ключей SSH печатает отпечатки точно в этом формате, поэтому значение, которое вы видите в браузере, можно сравнить символ в символ с тем, что показывает сервер. Как только вы принимаете ключ хоста, SSH сохраняет его в ~/.ssh/known_hosts и громко предупреждает вас — отказываясь подключаться — если он когда-нибудь изменится. Это предупреждение — не помеха, которую обходят флагом; это сработавшая тревога. Единственное рутинное исключение — сервер, который был законно пересобран; в этом случае администратор должен был заранее опубликовать новый отпечаток, а вы удаляете старую запись командой ssh-keygen -R имя-хоста перед повторным подключением.
Гигиена authorized_keys и known_hosts
Каждая строка в файле authorized_keys сервера — это дверь, и двери остаются открытыми ещё долго после того, как человек, которому они были нужны, ушёл. Ноутбук подрядчика, задание непрерывной интеграции, ключ, созданный на машине, которая с тех пор стёрта, коллега, сменивший команду два года назад, — каждая из них строка, которая всё ещё работает, и каждая — учётные данные, за которыми вы больше не следите. Аудит прост и стоит того каждые несколько месяцев: скопируйте файл, вставьте его во вкладку «Проверить» набора ключей SSH и посмотрите, что вернётся. Дубликаты — один и тот же открытый ключ дважды — означают, что кто-то вставил ключ снова вместо проверки, и их следует свести к одной строке. Слабые записи — RSA ниже 2048, DSA, ssh-dss — следует удалить и заменить. А любую строку, чей комментарий называет человека, машину или цель, которые вы больше не узнаёте, следует рассматривать как дверь, которую нужно закрыть, пока её владелец не сможет её заявить.
known_hosts заслуживает такого же внимания с другой стороны. В нём записан ключ хоста каждого сервера, к которому вы подключались, и SSH сверяет с ним каждое новое подключение. Некоторые записи хэшированы — |1|, за которым следует base64, — что скрывает имя хоста; это функция конфиденциальности для ноутбуков, которые могут быть потеряны или проверены. Набор ключей SSH сообщает о таких записях как о хэшированных, а не притворяется, что они читаемы, потому что хэшированную запись нельзя проверить по опубликованному отпечатку, ей можно только доверять как уже принятой. Сам файл — тоже свидетельство: known_hosts, полный серверов, которыми вы больше не пользуетесь, — это карта того, где побывали ваши учётные данные, а его обрезка ничего не стоит. Вместе эти два файла — полная запись вашего SSH-доверия в обоих направлениях: кто может войти от вашего имени и каким машинам вы доверяете быть самими собой, — и оба тихо гниют, если никто не смотрит.
Когда ключ утёк — и замечание о парольной фразе
Утёкший ключ — это не загадка, которую сначала расследуют, а потом действуют; это ключ, который нужно заменить, и порядок действий короток. Создайте новую пару ключей. Удалите старый открытый ключ из authorized_keys на каждом сервере и в каждом сервисе — на ваших серверах, в Git-хостинге, в конвейерах развёртывания, везде, где ключ был установлен. Затем проверьте, до чего мог дотянуться старый ключ, и поищите что-нибудь неуместное: новые строки в authorized_keys, которые вы не добавляли, входы в часы, когда вы не работали, незнакомые процессы. Если найдёте что-то, рассматривайте это как взлом, а не как испуг, и расследуйте дальше. Чего делать нельзя, так это удалить старый закрытый ключ со своего ноутбука и считать работу выполненной: удаление вашей копии ничего не делает с копиями, которые утекли, а открытый ключ, всё ещё сидящий в authorized_keys, — это по-прежнему работающая дверь.
Парольная фраза не меняет этот контрольный список, но меняет срочность его выполнения. Защищённый парольной фразой ключ, утёкший в виде файла, всё равно остаётся проблемой — злоумышленник может пытаться угадать парольную фразу офлайн, со скоростью машины, — но сильная парольная фраза даёт вам время на ротацию до того, как угадывание удастся. Незашифрованный ключ не даёт времени вовсе, и именно поэтому этот сайт прямо говорит о том, что производит его генератор: версия 1 создаёт незашифрованные ключи без опции парольной фразы, потому что bcrypt-KDF OpenSSH для зашифрованных закрытых ключей — это объём версии 2. Если вы создаёте ключ здесь, защитите файл командой chmod 600 и добавьте парольную фразу на своём компьютере командой ssh-keygen -p — это занимает десять секунд, преобразует файл на месте и является самой ценной привычкой во всей этой статье. Создайте ключ, задайте парольную фразу, установите только открытую половину, проверяйте файлы дважды в год и сверяйте каждый отпечаток, прежде чем ему доверять: это и есть вся дисциплина, и она умещается на каталожной карточке.