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

Публичный SSH-ключ

2026/10/14 16:11

#Intermediate

Что такое публичный SSH-ключ в криптовалютной сфере?

Публичный SSH-ключ — это общедоступная часть пары SSH-ключей. Он позволяет серверу убедиться, что пользователь владеет соответствующим приватным ключом, прежде чем предоставить удалённый доступ.

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

SSH расшифровывается как Secure Shell — протокол для безопасного удалённого входа в систему, выполнения команд, передачи файлов и администрирования серверов.

В официальной документации GitHub по SSH объясняется, что SSH обеспечивает защищённый канал в незащищённой сети.

Публичный SSH-ключ — это не то же самое, что публичный ключ криптокошелька, адрес блокчейна, сид-фраза или ключ подписи валидатора.

Это учётные данные для управления доступом к компьютерам и серверам, а не ключ для расходования криптоактивов в блокчейне.

Публичный ключ обычно можно безопасно передавать другим, поскольку он не раскрывает приватный ключ.

Соответствующий приватный ключ необходимо хранить в секрете: именно он подтверждает личность пользователя при аутентификации SSH.

В официальной документации Microsoft по аутентификации на основе ключей OpenSSH объясняется, что публичный ключ размещают на SSH-сервере и его можно передавать без риска раскрытия приватного ключа.

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

Почему публичные SSH-ключи важны в криптовалютной сфере

Публичные SSH-ключи важны в криптовалютной сфере, поскольку инфраструктура блокчейнов часто управляется через удалённые серверы Linux или облачные серверы.

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

Оператор полной ноды может использовать SSH для администрирования клиента исполнения, настройки сети, управления хранилищем и защиты RPC-эндпоинтов.

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

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

В официальном руководстве Ethereum по запуску ноды объясняется, что для работы нод и валидаторов нужны программное обеспечение, клиенты, синхронизация, API и соответствующая настройка инфраструктуры.

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

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

Аутентификация по SSH-ключам снижает зависимость от паролей за счёт асимметричной криптографии.

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

Как работает аутентификация по публичному SSH-ключу

Для аутентификации по публичному SSH-ключу используется пара соответствующих друг другу публичного и приватного ключей.

Публичный ключ копируют в учётную запись на сервере, которой нужно предоставить доступ.

Приватный ключ хранится на локальном компьютере пользователя, аппаратном устройстве или в защищённой системе управления ключами.

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

Сервер проверяет это подтверждение с помощью сохранённого публичного ключа.

Если подтверждение действительно и разрешения учётной записи настроены правильно, сервер разрешает вход.

Если приватный ключ не соответствует сохранённому публичному ключу, аутентификация не пройдёт.

В документации Microsoft по OpenSSH объясняется, что при аутентификации на основе ключей SSH-сервер и клиент сопоставляют публичный ключ на стороне сервера с приватным ключом на стороне клиента.

Эта модель эффективна, поскольку приватному ключу не нужно передаваться по сети.

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

Публичный ключ и приватный ключ

Публичный и приватный SSH-ключи создаются вместе как пара.

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

Приватный ключ должен оставаться в секрете на устройстве пользователя или в защищённом хранилище ключей.

В официальном руководстве OpenBSD по ssh-keygen объясняется, что ssh-keygen создаёт ключи аутентификации SSH и сохраняет публичный ключ под тем же именем, что и приватный, добавляя расширение .pub.

Если кто-то получит только публичный ключ, обычно он не сможет войти в систему от имени пользователя.

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

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

В криптоинфраструктуре кража приватного SSH-ключа может привести к взлому сервера, простою валидатора, изменению конфигурации, установке вредоносных программ или краже конфиденциальных файлов.

Публичный ключ служит идентификатором, а приватный — подтверждением.

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

Публичный SSH-ключ и публичный ключ криптокошелька

Публичный SSH-ключ отличается от публичного ключа криптокошелька.

Публичный SSH-ключ используется для аутентификации на сервере.

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

Публичный SSH-ключ не предназначен для получения криптовалюты в блокчейне.

Публичный ключ криптокошелька или созданный на его основе адрес обычно не используется для входа на сервер через SSH.

В обоих случаях применяется криптография с открытым ключом, но эти ключи относятся к разным системам.

Путаница между ними может привести к серьёзным ошибкам.

Не вставляйте сид-фразу криптокошелька в инструмент SSH.

Не используйте ключ подписи валидатора как обычный SSH-ключ.

Храните ключи доступа к инфраструктуре отдельно от ключей кошелька, ключей валидатора, ключей для вывода средств и API-ключей.

Публичный SSH-ключ и адрес блокчейна

Публичный SSH-ключ — это не адрес блокчейна.

Адрес блокчейна обычно представляет собой сокращённое представление, полученное на основе публичного ключа кошелька или структуры аккаунта.

Публичный SSH-ключ, как правило, представляет собой более длинную текстовую строку, которую SSH-программы используют для аутентификации пользователя или хоста.

Адрес блокчейна можно передать другим, чтобы они отправили токены или просмотрели ончейн-активность.

Публичный SSH-ключ можно передать администратору сервера, чтобы тот предоставил доступ к системе.

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

Публичный SSH-ключ обычно раскрывает меньше финансовой информации, однако по нему всё равно можно определить человека или устройство в журналах инфраструктуры.

Адрес блокчейна показывает, куда можно отправить активы.

Публичный SSH-ключ подтверждает, какой приватный ключ может получить доступ к учётной записи на сервере.

С обоими типами данных следует обращаться осторожно, но они используются в разных отношениях доверия.

Как выглядит публичный SSH-ключ

Публичный SSH-ключ обычно представляет собой одну строку текста.

Часто он начинается с обозначения типа ключа, например ssh-ed25519, ecdsa-sha2-nistp256 или ssh-rsa.

В середине находится длинное закодированное значение ключа.

В конце может быть комментарий, например имя пользователя, адрес электронной почты, название устройства или метка даты создания.

Комментарий помогает людям позднее определить ключ.

Сам по себе комментарий не обеспечивает защиту.

Имя файла с публичным ключом часто заканчивается на .pub.

Соответствующий файл приватного ключа может иметь похожее имя, но без окончания .pub.

В руководстве OpenBSD по ssh-keygen объясняется, что публичный ключ хранится в файле с тем же именем, что и приватный, с добавлением суффикса .pub.

Перед копированием всегда проверяйте, что выбрали файл .pub, а не файл приватного ключа.

authorized_keys

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

Во многих Unix-подобных системах этот файл находится в каталоге .ssh пользователя.

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

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

Забытый старый ключ в authorized_keys может превратиться в скрытый бэкдор.

Публичный ключ, скопированный не в ту учётную запись, может предоставить доступ с неправильными правами.

Файл authorized_keys учётной записи root особенно чувствителен, поскольку доступ root позволяет управлять всем сервером.

Операторам криптонод следует регулярно проверять authorized_keys и удалять ненужные ключи.

По возможности предоставляйте доступ именным учётным записям с правами sudo, а не разрешайте прямой вход root.

Надлежащее управление authorized_keys помогает уменьшить масштаб возможного ущерба при краже приватного ключа.

ssh-keygen

ssh-keygen — стандартный инструмент OpenSSH для создания пар SSH-ключей и управления ими.

В руководстве OpenBSD по ssh-keygen указано, что инструмент создаёт ключи аутентификации SSH, управляет ими и преобразует их.

В том же руководстве сказано, что если тип ключа не указан, ssh-keygen по умолчанию создаёт ключ Ed25519.

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

Некоторые системы по-прежнему поддерживают ключи RSA или ECDSA для совместимости.

В зависимости от среды и политики могут не рекомендоваться более старые алгоритмы или ключи небольшой длины.

При выборе типа ключа следуйте актуальным рекомендациям для операционной системы и OpenSSH.

При создании ключа добавьте понятный комментарий, чтобы позднее его можно было определить.

В криптоинфраструктуре комментарии вроде validator-admin-laptop-2026 или node-maintenance-key упрощают аудит.

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

Парольные фразы

Парольная фраза шифрует или защищает приватный ключ в состоянии хранения.

В руководстве OpenBSD по ssh-keygen объясняется, что при создании ключей ssh-keygen запрашивает парольную фразу, а утерянную фразу восстановить нельзя.

Парольная фраза обеспечивает дополнительную защиту на случай, если файл приватного ключа скопируют или украдут с ноутбука.

Без парольной фразы украденный приватный ключ злоумышленник может использовать сразу.

Если парольная фраза задана, злоумышленнику также придётся угадать или украсть её.

Это не делает уязвимые системы безопасными, но усиливает защиту.

Операторам криптоинфраструктуры, как правило, следует защищать важные приватные SSH-ключи надёжными парольными фразами.

Для автоматизированных систем могут потребоваться особые настройки, поскольку запрос парольной фразы без участия пользователя способен нарушить работу скриптов.

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

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

ssh-agent

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

В документации Microsoft по OpenSSH ssh-agent и ssh-add указаны как инструменты для безопасного хранения приватных ключей при аутентификации на основе ключей.

ssh-agent повышает удобство, но при слабой защите локального компьютера или небезопасной переадресации агента он также создаёт риски.

Переадресация агента позволяет пользователю подключаться с одного сервера к другому, используя локальный агент.

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

Операторам криптоинфраструктуры следует избегать ненужной переадресации агента в инфраструктуре валидаторов и нод.

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

Часто лучше подключаться напрямую с защищённой рабочей станции администратора или использовать усиленно защищённый бастион-хост.

ssh-agent полезен, но его следует считать частью периметра безопасности.

Взлом рабочей станции может поставить под угрозу все идентификаторы SSH, загруженные в агент.

Публичные SSH-ключи для нод валидаторов

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

Публичные SSH-ключи помогают валидаторам отказаться от входа по паролю на серверах, которые могут стать целью злоумышленников.

Стейкер Ethereum, работающий самостоятельно, может использовать SSH для управления клиентами исполнения и консенсуса, клиентами валидатора, межсетевыми экранами, агентами мониторинга и системными службами.

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

Эту инфраструктуру следует тщательно защищать, поскольку простой валидатора может привести к снижению вознаграждений.

Взлом сервера валидатора может привести к пропуску подтверждений, неправильной конфигурации или перебоям в работе.

Доступ по SSH обычно не даёт прямого контроля над учётными данными для вывода средств, если они безопасно хранятся в другом месте.

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

Валидаторам следует хранить SSH-ключи отдельно от ключей подписи валидатора и ключей для вывода средств.

Не следует считать доступ к инфраструктуре и хранение активов одной и той же областью безопасности.

Публичные SSH-ключи для полных нод

Полным нодам также полезна аутентификация по публичным SSH-ключам.

Полная нода может хранить данные блокчейна, предоставлять локальные API, обслуживать кошельки, проверять транзакции или поддерживать работу приложений.

В руководстве по нодам Ethereum предупреждается, что при неправильной настройке публичные RPC-эндпоинты могут стать доступными через локальные сети и публичные IP-адреса.

Для управления настройками ноды и правилами межсетевого экрана часто используют SSH.

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

Полная нода может не хранить приватные ключи кошелька, но всё равно может содержать чувствительные данные.

Например, скомпрометированная нода может предоставлять пользователю ложные данные, нарушить работу приложения или раскрыть сведения о внутренней сети.

Предоставляйте доступ по публичному SSH-ключу только администраторам, которым он необходим.

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

Полная нода входит в модель доверия криптовалютной системы, поэтому контроль доступа к серверу имеет значение.

Публичные SSH-ключи для разработчиков криптопроектов

Разработчики криптопроектов используют публичные SSH-ключи для размещения кода, развёртывания, тестовых сред и администрирования серверов.

Платформы Git часто позволяют добавлять публичные SSH-ключи, чтобы пользователи могли отправлять изменения в репозитории и получать их без постоянного ввода пароля.

В официальном руководстве GitHub по созданию SSH-ключа объясняется, как создать новый SSH-ключ и добавить его в ssh-agent.

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

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

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

При замене устройств или уходе участников команды удаляйте старые ключи с платформ для размещения кода.

Не добавляйте приватные ключи в репозитории.

Если проекту нужна более надёжная целостность контроля версий, используйте подписанные коммиты или другие методы проверки.

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

Публичные SSH-ключи и майнинговая инфраструктура

Для управления серверами, системами мониторинга, прокси, инструментами прошивки и внутренней инфраструктурой в майнинге часто используют SSH-ключи.

Даже если сами майнинговые устройства управляются через отдельные системы, для вспомогательных серверов всё равно может использоваться SSH.

Украденный приватный SSH-ключ может позволить злоумышленнику нарушить работу майнинга или изменить конфигурационные данные.

Для майнеров Proof of Work простой может означать прямую потерю выручки: устройства продолжают потреблять электроэнергию или перестают выполнять полезную работу.

Операторам майнинга следует использовать отдельные ключи для мониторинга, развёртывания, аварийного доступа и автоматизации.

Не следует использовать один приватный ключ для всех серверов майнингового парка.

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

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

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

Поэтому управление публичными SSH-ключами — часть обеспечения безопасности майнинга.

Публичные SSH-ключи и облачные серверы

Многие криптоноды и валидаторы работают на виртуальных частных серверах, выделенных физических серверах или в облачной инфраструктуре.

При создании нового сервера облачные провайдеры часто предлагают загрузить публичный SSH-ключ.

Провайдер устанавливает этот ключ, чтобы после запуска сервера пользователь мог безопасно войти в систему.

Такой способ безопаснее отправки пароля по электронной почте или использования пароля по умолчанию.

Однако загрузка публичного ключа автоматически не делает сервер полностью защищённым.

Приватный ключ по-прежнему нужно защищать.

На сервере по-прежнему необходимо устанавливать исправления.

Правила межсетевого экрана по-прежнему нужно настраивать тщательно.

Не открывайте порты RPC, API валидатора, панели мониторинга и администрирования без понимания связанных с этим рисков.

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

Ключи хоста и пользовательские ключи

В SSH используются как пользовательские ключи, так и ключи хоста.

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

Ключ хоста подтверждает подлинность сервера для клиента.

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

Эта проверка помогает предотвратить атаки типа «человек посередине», при которых злоумышленник выдаёт себя за сервер.

Публичный ключ пользователя добавляют в файл authorized_keys на сервере.

Публичный ключ хоста клиенты используют для проверки личности сервера; после подтверждения он часто сохраняется в known_hosts.

Операторам криптоинфраструктуры не следует бездумно игнорировать предупреждения о ключе хоста.

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

Пользовательские ключи определяют, кто может войти в систему, а ключи хоста помогают подтвердить, к какому серверу подключается пользователь.

Отпечаток ключа

Отпечаток SSH-ключа — это сокращённое представление публичного ключа, используемое для проверки.

Отпечатки упрощают сравнение ключей: не нужно читать длинную строку публичного ключа целиком.

В руководстве OpenBSD по ssh-keygen описаны параметры для отображения отпечатков ключей.

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

При подключении к серверу пользователь может сравнить отпечаток ключа хоста с известным корректным значением.

Для криптоинфраструктуры это важно: неправильный ключ может предоставить доступ не тому человеку или подключить оператора не к тому серверу.

Отпечатки особенно полезны в командах, где ключи согласовываются через системы обработки запросов, контроля доступа или проверки безопасности.

Комментарий к публичному ключу легко изменить, а отпечаток вычисляется на основе самого ключа.

При проверке личности операторам следует полагаться на отпечатки, а не только на комментарии.

Надёжная проверка отпечатков снижает риск ошибок при выдаче ключей и реагировании на инциденты.

Ротация ключей

Ротация ключей — это замена старых пар SSH-ключей новыми и удаление старых публичных ключей из систем, которым они были доверены.

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

В рекомендациях NIST SP 800-57 по управлению ключами приведены общие сведения об управлении криптографическими ключами и связанных с этим вопросах.

Криптокомандам следует планировать ротацию ключей до возникновения чрезвычайной ситуации.

Команда должна знать, где установлен каждый публичный ключ.

Команда должна знать, кому принадлежит каждый ключ.

Команда должна знать, какие серверы, репозитории и системы развёртывания доверяют каждому ключу.

Без реестра старые публичные SSH-ключи могут оставаться активными годами.

Это создаёт ненужную поверхность для атак.

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

Реестр ключей

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

В отчёте NISTIR 7966 об управлении доступом SSH рассматривается управление пользовательскими SSH-ключами и объясняется, что для доступа на основе SSH нужны процессы выдачи, прекращения и мониторинга доступа.

Это особенно важно для криптокомпаний, валидаторов и инфраструктурных команд, поскольку SSH-доступ может предоставлять широкие привилегии.

Реестр ключей должен показывать, кто может получить доступ к каждому серверу.

В нём должна быть указана причина предоставления такого доступа.

В нём должно быть указано, когда доступ следует прекратить.

В нём следует отмечать, принадлежит ли ключ человеку, задаче автоматизации, конвейеру развёртывания или аварийной учётной записи.

Без реестра невозможно уверенно удалить старые ключи.

Если их не удалять, старые ключи становятся постоянным скрытым способом доступа.

Надлежащее управление публичными SSH-ключами начинается с понимания того, какие ключи существуют.

Принцип минимальных привилегий

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

Ключу мониторинга не нужны права root, если он должен только считывать показатели.

Ключ развёртывания не должен позволять выводить активы, редактировать ключи валидатора или читать не относящиеся к задаче секреты.

Срок действия ключа подрядчика должен истекать после завершения проекта.

По возможности ограничьте ключ автоматизации нужной ему командой или каталогом.

Использовать один ключ администратора везде удобно, но это создаёт высокий риск.

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

Следует рассматривать доступ SSH к криптоинфраструктуре как систему управления разрешениями.

Для разных ролей используйте разные ключи.

Для разных сред — например, тестовой, предварительной и промышленной — устанавливайте разные правила доступа.

Публичный SSH-ключ и вход под root

Вход под root предоставляет прямой административный доступ к серверу.

Прямой вход root по SSH может быть рискованным: в случае успешного входа злоумышленник сразу получает полный контроль.

Многие операторы отключают прямой вход root и используют именную учётную запись с правами sudo.

Это может упростить контроль, поскольку административные команды можно связать с конкретной учётной записью.

Это также может снизить риск автоматизированных атак на пользователя root.

Прямой доступ root к криптонодам и серверам валидаторов следует строго ограничивать.

В учётной записи администратора должны быть только те публичные SSH-ключи, которые нужны реальным операторам.

Во время аудита серверов удаляйте старые записи из authorized_keys для root.

Аварийный доступ следует документировать и защищать, а не организовывать на ходу.

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

Публичный SSH-ключ и вход по паролю

Аутентификацию по публичному SSH-ключу часто используют, чтобы ограничить или отключить вход по паролю.

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

На серверах, доступных через интернет, вход по паролю может постоянно привлекать автоматизированные попытки подбора.

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

Однако аутентификация по ключу — не волшебное решение.

Если приватный ключ украден, не зашифрован или используется повсюду, риск становится серьёзным.

Надёжная конфигурация часто сочетает SSH-ключи, отключённый вход по паролю, запрет прямого входа root, правила межсетевого экрана, управление обновлениями и мониторинг.

Некоторые команды также используют VPN, бастион-хосты, ключи с аппаратной защитой или SSH-сертификаты.

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

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

SSH-ключи с аппаратной защитой

В SSH-ключах с аппаратной защитой приватные ключи хранятся на аппаратном аутентификаторе или устройстве безопасности.

Это может снизить вероятность того, что вредоносная программа просто скопирует файл приватного ключа с ноутбука.

Современный OpenSSH поддерживает типы ключей безопасности, например ecdsa-sk и ed25519-sk, в средах, совместимых с соответствующими аутентификаторами.

В руководстве OpenBSD по ssh-keygen типы ключей безопасности перечислены среди поддерживаемых вариантов создания ключей.

SSH-ключи с аппаратной защитой могут быть полезны администраторам криптоинфраструктуры, поскольку доступ к серверам может быть крайне чувствительным.

Они также требуют операционного планирования: в случае потери устройства необходимо восстановить доступ и заменить ключ.

Командам следует разработать процедуры аварийного доступа, не зависящие от аппаратного ключа одного человека.

Аппаратные ключи наиболее эффективны в сочетании с надлежащим реестром, разделением ролей и удалением старых публичных ключей.

Они не защищают от всех типов атак, например от выполнения вредоносных команд после легитимного входа.

Их лучше рассматривать как один из надёжных инструментов в рамках более широкой системы безопасности.

SSH-сертификаты

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

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

В руководстве OpenBSD по ssh-keygen описана поддержка подписания идентификаторов сертификатов с помощью ключа центра сертификации.

SSH-сертификаты могут упростить управление доступом в крупных криптокомандах.

Они позволяют предоставлять инженерам, подрядчикам, специалистам по реагированию на чрезвычайные ситуации и системам автоматизации краткосрочный доступ.

Они могут сократить число забытых записей в authorized_keys.

При этом ключ центра сертификации необходимо тщательно защищать.

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

Небольшие команды могут использовать обычные файлы authorized_keys, а крупным командам могут подойти сертификаты для управления доступом.

Оптимальный вариант зависит от размера команды, масштаба инфраструктуры и уровня зрелости системы безопасности.

Публичные SSH-ключи и автоматизация

В автоматизации часто используют SSH-ключи для развёртывания, резервного копирования, мониторинга, передачи файлов и операций между серверами.

Автоматизированный SSH-доступ может быть мощным инструментом, поскольку система может работать без ввода пользователем парольной фразы при каждом подключении.

Поэтому ключи автоматизации особенно опасны, если их не ограничивать.

Не используйте один ключ автоматизации для несвязанных задач.

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

Отключайте ключ после прекращения работы задачи автоматизации.

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

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

Ограничения для ключа позволяют уменьшить ущерб, если один из компонентов будет скомпрометирован.

Автоматизация делает управление ключами ещё важнее, а не менее важным.

Распространённые ошибки при работе с публичными SSH-ключами

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

Другая ошибка — использовать один и тот же SSH-ключ для всех серверов и ролей.

Третья — оставлять старые публичные ключи в authorized_keys, когда человеку или устройству больше не нужен доступ.

Четвёртая — не устанавливать парольную фразу для важного приватного ключа, хранящегося на ноутбуке.

Пятая — включать переадресацию агента повсюду, не понимая связанных с ней рисков.

Шестая — доверять неизвестным запросам о ключе хоста, не проверив отпечаток.

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

Восьмая — путать публичные SSH-ключи с публичными ключами криптокошельков.

Девятая — хранить секреты валидатора, ключи кошелька и SSH-ключи вместе на одном плохо защищённом сервере.

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

Преимущества публичных SSH-ключей

Первое преимущество публичных SSH-ключей — более надёжная защита удалённого входа по сравнению с использованием только простого пароля.

Второе — снижение уязвимости к подбору пароля методом перебора.

Третье — упрощение контроля доступа к серверам, требующим регулярного администрирования.

Четвёртое — совместимость с рабочими процессами разработчиков, системами контроля версий, инструментами развёртывания и облачными серверами.

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

Шестое — улучшение аудита, если для каждого человека и каждой роли используется отдельный ключ.

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

Эти преимущества особенно заметны, когда публичные ключи внесены в реестр, регулярно проверяются, ротируются и удаляются после того, как становятся ненужными.

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

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

Риски и ограничения публичных SSH-ключей

Первый риск — кража приватного ключа.

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

Второй риск — распространение ключей по множеству систем.

Это происходит, когда публичные ключи копируют во множество систем, и никто не знает, каким из них доверяют.

Третий риск — устаревший доступ.

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

Четвёртый риск — чрезмерные привилегии.

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

Пятый риск — слабая защита рабочей станции.

Даже защищённый сервер можно скомпрометировать, украв ключ с заражённого ноутбука администратора.

Шестой риск — путаница между SSH-ключами, ключами кошелька, API-ключами и ключами валидатора.

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

Как оценить настройки публичного SSH-ключа

Начните с проверки: у каждого разрешённого публичного ключа должен быть известный владелец.

Затем убедитесь, что у каждого ключа есть чёткое назначение.

Проверьте, нужен ли ещё каждый ключ.

Проверьте, защищён ли приватный ключ парольной фразой, аппаратным устройством или защищённой системой управления ключами.

Проверьте, не предоставлен ли ключу доступ к большему числу серверов, чем необходимо.

Проверьте, отключён ли вход root или строго ли он контролируется.

Проверьте, отключён ли вход по паролю там, где это уместно.

Убедитесь, что отпечатки ключей хостов проверяются, а предупреждения known_hosts расследуются.

Проверьте, удаляются ли старые ключи после кадровых изменений, замены устройств или изменения автоматизации.

Надёжные настройки SSH позволяют объяснить и проверить каждый доступ, а также быстро его отозвать.

Публичный SSH-ключ и реагирование на инциденты

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

Пользователю следует создать новую пару ключей на чистом устройстве.

На каждом затронутом сервере необходимо проверить наличие несанкционированных входов, изменённых файлов, новых пользователей, изменённых файлов authorized_keys, вредоносных программ и неизвестных служб.

Операторам валидаторов и нод также следует проверить конфигурацию клиентов, правила межсетевого экрана, доступность RPC, оповещения мониторинга и журналы служб.

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

Компрометация SSH-ключа — это не только проблема со входом в систему.

Она может перерасти в полномасштабный инцидент инфраструктуры.

Командам следует подготовить письменную процедуру отзыва SSH-ключей до чрезвычайной ситуации.

Реестр ключей ускоряет реагирование на инцидент: команда знает, где необходимо удалить публичный ключ.

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

FAQ

Что такое публичный SSH-ключ?

Публичный SSH-ключ — это общедоступная часть пары SSH-ключей, которую сервер использует, чтобы проверить, владеет ли пользователь соответствующим приватным ключом.

Безопасно ли передавать публичный SSH-ключ?

Да, публичный SSH-ключ обычно можно безопасно передавать, но соответствующий приватный ключ должен оставаться в секрете.

Публичный SSH-ключ — это то же самое, что публичный ключ криптокошелька?

Нет. Публичный SSH-ключ используется для аутентификации на сервере, а публичный ключ криптокошелька — для подписей в блокчейне и создания адресов.

Зачем криптовалютным валидаторам публичные SSH-ключи?

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

Что такое authorized_keys?

authorized_keys — это файл на стороне сервера, в котором перечислены публичные SSH-ключи, которым разрешён вход в систему под конкретной учётной записью.

Что произойдёт, если мой приватный SSH-ключ украдут?

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

Стоит ли использовать один SSH-ключ для всех криптосерверов?

Нет. Использование отдельных SSH-ключей для разных ролей, устройств и сред уменьшает ущерб в случае компрометации одного из ключей.

Даёт ли публичный SSH-ключ контроль над моими криптоактивами?

Нет, публичный SSH-ключ не даёт прямого контроля над криптоактивами, но может предоставлять доступ к серверам, которые поддерживают криптоинфраструктуру.

Можно ли удалить публичный SSH-ключ?

Да. Удаление публичного SSH-ключа из authorized_keys или учётной записи службы отзывает доступ соответствующего приватного ключа в этой системе.

Какой тип SSH-ключа лучше?

Оптимальный тип ключа зависит от среды. Современный OpenSSH обычно поддерживает Ed25519 и ключи безопасности, а для совместимости могут потребоваться другие поддерживаемые типы.

Заключение

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

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

Публичный SSH-ключ — это не публичный ключ кошелька, адрес блокчейна, сид-фраза, ключ подписи валидатора или учётные данные для вывода средств.

Он используется для управления доступом к инфраструктуре, а не для прямого владения активами в блокчейне.

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

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

Командам также следует хранить отдельно пользовательские ключи, ключи автоматизации, ключи валидатора, ключи кошелька и API-ключи.

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

Новичкам лучше всего представлять публичный SSH-ключ как публичный идентификатор для входа на сервер.

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

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

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