Как создать SSH ключи с помощью OpenSSH на macOS или Linux

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

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

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

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

• Криптографическая стойкость: RSA-ключ длиной 4096 бит или ключ Ed25519 вычислительно невозможно подобрать перебором с использованием современного оборудования.
• Никаких секретов, передаваемых по сети: Закрытый ключ никогда не покидает ваш компьютер. Протокол аутентификации доказывает владение ключом без его раскрытия.
• Готовность к автоматизации: CI/CD-конвейеры, плейбуки Ansible, задания rsync и резервное копирование на основе cron — всё это требует неинтерактивной аутентификации. SSH-ключи делают это возможным без встраивания паролей в открытом виде в скрипты.
• Возможность аудита: Каждую пару ключей можно однозначно идентифицировать по её отпечатку, что позволяет легко отозвать один скомпрометированный ключ без смены учётных данных повсюду.
• Совместимость с authorized_keys ACL: Вы можете ограничить конкретный открытый ключ выполнением только одной команды, привязать его к исходному IP или запретить перенаправление портов — возможности, которые аутентификация по паролю не может воспроизвести.

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

Выбор правильного алгоритма ключа

Оригинальная документация OpenSSH и большинство устаревших руководств по умолчанию используют RSA. Ситуация изменилась. Вот точное сравнение всех алгоритмов, которые ssh-keygen поддерживает сегодня:

Ed25519 — правильный выбор по умолчанию в 2024 году. Он создаёт более короткие ключи, подписывает быстрее, а его фиксированный размер ключа исключает риск случайной генерации ключа недостаточного размера. RSA на 4096 бит остаётся приемлемым для сред, которые должны взаимодействовать со старыми системами, не поддерживающими Ed25519 (OpenSSH < 6.5, выпущен в 2014 году).

Предварительные требования

• Рабочая станция на macOS или Linux с установленным OpenSSH. Обе операционные системы поставляются с OpenSSH по умолчанию. Проверьте с помощью:

ssh -V

• Сетевой доступ к удалённому серверу, на котором у вас есть учётная запись (root или непривилегированная).
• Базовые навыки работы с терминалом.

В дистрибутивах Linux с минимальной установкой (Alpine, некоторые netinstall-версии Debian) установите клиентские инструменты с помощью:

# Debian / Ubuntu
sudo apt install openssh-client

# RHEL / CentOS / AlmaLinux / Rocky
sudo dnf install openssh-clients

Шаг 1: Откройте терминал

macOS: Нажмите Cmd + Space, введите Terminal и нажмите Enter. Либо перейдите в Программы > Утилиты > Терминал. Опытные пользователи могут использовать iTerm2 или встроенный терминал в VS Code.

Linux: Нажмите Ctrl + Alt + T в большинстве настольных сред или запустите эмулятор терминала вашего дистрибутива из меню приложений.

Шаг 2: Сгенерируйте пару SSH-ключей

Генерация ключа Ed25519 (рекомендуется)

ssh-keygen -t ed25519 -C "your_email@example.com"

Флаг -C добавляет удобочитаемый комментарий к открытому ключу. Используйте ваш адрес электронной почты, имя хоста или описательную метку, например "deploy-key-prod" — это не имеет криптографической функции, но незаменимо при аудите файлов authorized_keys, в которых накапливаются десятки записей.

Генерация ключа RSA (для совместимости с устаревшими системами)

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

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

Генерация именованного ключа для конкретного хоста

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

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_prod_webserver -C "prod-webserver-2024"

Шаг 3: Выберите место хранения

После выполнения ssh-keygen вы увидите:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/youruser/.ssh/id_ed25519):

Нажмите Enter, чтобы принять значение по умолчанию (~/.ssh/id_ed25519 для Ed25519, ~/.ssh/id_rsa для RSA), или введите пользовательский путь. Расположение по умолчанию подходит для одного ключа общего назначения. Для ключей, привязанных к конкретной роли, всегда указывайте описательное имя файла, как показано в предыдущем шаге.

Важное замечание о правах доступа к файлам: Каталог ~/.ssh/ должен иметь режим 700, а файлы закрытых ключей — режим 600. OpenSSH откажется использовать ключи с чрезмерно разрешительными правами доступа и выведет предупреждение. Если вы когда-либо копируете ключи между машинами, немедленно проверьте права доступа:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Шаг 4: Установите парольную фразу

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Парольная фраза шифрует файл закрытого ключа на диске с использованием AES-256-CBC (в современном OpenSSH). Если злоумышленник получит ваш файл закрытого ключа — через украденный ноутбук, скомпрометированную резервную копию или неправильно настроенный облачный снимок — надёжная парольная фраза является последним рубежом защиты, не позволяющим использовать его.

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

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

Your identification has been saved in /home/youruser/.ssh/id_ed25519
Your public key has been saved in /home/youruser/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:abc123XYZexampleFingerprint your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
|        .o+.     |
...
+----[SHA256]-----+

Запишите отпечаток. Он понадобится вам для проверки идентичности ключа при аудите серверов.

Шаг 5: Скопируйте открытый ключ на удалённый сервер

Метод 1: ssh-copy-id (самый быстрый)

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server.com

Флаг -i явно указывает, какой открытый ключ копировать, предотвращая загрузку ssh-copy-id всех ключей из вашего агента. Вам будет предложено ввести пароль сервера один раз. Инструмент автоматически обрабатывает создание каталога, добавление в файл и установку прав доступа.

Метод 2: Ручное развёртывание (когда ssh-copy-id недоступен)

Это правильный подход, когда удалённая система работает под управлением Windows, является сетевым устройством или контейнером без ssh-copy-id в пути.

Сначала отобразите ваш открытый ключ:

cat ~/.ssh/id_ed25519.pub

Скопируйте весь вывод — это одна строка, начинающаяся с ssh-ed25519 (или ssh-rsa). Затем войдите на сервер и добавьте её:

ssh user@your-server.com

После подключения:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...your-full-public-key... your_email@example.com" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Распространённая ошибка: Использование > вместо >> перезаписывает весь файл authorized_keys, блокируя все остальные ключи. Всегда используйте >> для добавления.

Метод 3: Передача по SSH одной командой

Если у вас уже есть доступ по паролю и вы хотите выполнить развёртывание без интерактивного входа:

cat ~/.ssh/id_ed25519.pub | ssh user@your-server.com "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Шаг 6: Проверьте соединение

ssh -i ~/.ssh/id_ed25519 user@your-server.com

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

ssh -vvv -i ~/.ssh/id_ed25519 user@your-server.com

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

Шаг 7: Настройте ~/.ssh/config для постоянных профилей хостов

Каждый раз вводить полную команду ssh -i ~/.ssh/id_ed25519_prod_webserver user@203.0.113.45 неудобно и медленно. Файл конфигурации SSH-клиента устраняет эту проблему:

nano ~/.ssh/config

Добавьте блок хоста:

Host prod-web
    HostName 203.0.113.45
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod_webserver
    Port 2222
    ServerAliveInterval 60

Теперь подключайтесь просто с помощью:

ssh prod-web

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

Управление несколькими ключами с помощью SSH-агента

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

Запустите агент и добавьте ключ:

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

На macOS вы можете сохранять ключи между перезагрузками, добавив следующее в ~/.ssh/config:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

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

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

ssh-add -l

Удаление конкретного ключа из агента:

ssh-add -d ~/.ssh/id_ed25519

Дополнительно: ограничение ключей в authorized_keys

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

command="/usr/bin/rsync --server ...",no-pty,no-agent-forwarding,no-port-forwarding ssh-ed25519 AAAA... backup-key

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

Усиление защиты SSH-демона после развёртывания ключей

После того как аутентификация на основе ключей заработала, полностью отключите аутентификацию по паролю на сервере. Отредактируйте /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Установите следующие директивы:

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin prohibit-password
AuthenticationMethods publickey

Перезагрузите демон, не разрывая текущий сеанс:

sudo systemctl reload sshd

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

Для серверов, работающих в средах cPanel VPS, учтите, что некоторые версии cPanel управляют собственной конфигурацией SSH. Убедитесь, что изменения sshd_config сохраняются после обновлений cPanel, проверив /etc/ssh/sshd_config.d/ на наличие файлов переопределения.

Ротация и отзыв SSH-ключей

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

Чтобы отозвать ключ: удалите его строку из ~/.ssh/authorized_keys на каждом сервере, где он был развёрнут. В стандартном OpenSSH нет централизованного механизма отзыва — именно поэтому важно вести учёт того, где развёрнут каждый отпечаток ключа.

Чтобы выполнить ротацию ключа:

1. Сгенерируйте новую пару ключей.
2. Разверните новый открытый ключ на всех целевых серверах.
3. Проверьте подключение с новым ключом.
4. Удалите старый открытый ключ из всех файлов authorized_keys.
5. Удалите или заархивируйте старый закрытый ключ локально.

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

Перенос ключей между машинами

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

Скопируйте закрытый ключ безопасно с помощью scp или rsync через SSH:

scp ~/.ssh/id_ed25519 newmachine.local:~/.ssh/id_ed25519

Либо используйте зашифрованный USB-накопитель или менеджер паролей, поддерживающий хранение SSH-ключей (1Password, Bitwarden и HashiCorp Vault поддерживают это). Никогда не отправляйте закрытые ключи по электронной почте и не храните их в незашифрованном облачном хранилище.

После переноса немедленно проверьте права доступа на новой машине:

chmod 600 ~/.ssh/id_ed25519

Проверка отпечатка хост-ключа сервера

При первом подключении к серверу OpenSSH отображает отпечаток хост-ключа сервера и просит вас подтвердить его:

The authenticity of host '203.0.113.45 (203.0.113.45)' can't be established.
ED25519 key fingerprint is SHA256:abc123XYZexample.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Никогда не вводите yes вслепую. Получите ожидаемый отпечаток через внеполосный канал — панель управления вашего хостинг-провайдера, коллегу, который настраивал сервер, или вывод консоли сервера. Этот шаг предотвращает атаки типа «человек посередине». Для сред виртуального хостинга ожидаемый отпечаток обычно указан в панели управления в разделе настроек SSH-доступа.

После принятия отпечаток сохраняется в ~/.ssh/known_hosts. Если отпечаток неожиданно изменится при последующем подключении, OpenSSH откажется подключаться и выведет предупреждение — воспринимайте это как серьёзное событие безопасности, требующее расследования перед продолжением.

Матрица решений и технический контрольный список

Используйте этот контрольный список, прежде чем считать настройку SSH-ключей готовой к производственному использованию:

• [ ] Алгоритм ключа — Ed25519 (или RSA 4096 для совместимости с устаревшими системами) — DSA и ECDSA 256 неприемлемы для новых развёртываний
• [ ] Права доступа к файлу закрытого ключа — 600; права доступа к каталогу ~/.ssh/ — 700
• [ ] На всех интерактивных пользовательских ключах установлена надёжная парольная фраза
• [ ] Ключи сервисных учётных записей без парольных фраз ограничены с помощью параметров authorized_keys (command=, from=, no-pty)
• [ ] PasswordAuthentication no установлен в /etc/ssh/sshd_config на всех серверах
• [ ] Применяется PermitRootLogin prohibit-password или PermitRootLogin no
• [ ] Отпечатки хост-ключей сервера проверены через внеполосный канал
• [ ] Существует реестр ключей, сопоставляющий каждый отпечаток с серверами, на которых он развёрнут
• [ ] График ротации ключей определён и внесён в календарь
• [ ] Блоки хостов ~/.ssh/config настроены во избежание ручного использования флага -i
• [ ] SSH-агент используется для предотвращения повторного ввода парольной фразы во время рабочих сеансов
• [ ] Записи known_hosts периодически проверяются на наличие устаревших или неожиданных записей

Часто задаваемые вопросы

В чём разница между SSH-ключами Ed25519 и RSA?

Ed25519 использует криптографию на эллиптических кривых с фиксированным 256-битным ключом, обеспечивающим примерно 128 бит безопасности, выполняет операции подписи быстрее RSA и создаёт более короткие строки ключей. RSA на 4096 бит обеспечивает сопоставимую безопасность, но работает медленнее и генерирует больший объём ключевого материала. Используйте Ed25519 для всех новых ключей, если только вам не нужно подключаться к системе с OpenSSH версии ниже 6.5.

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

Да, технически это возможно. Однако рекомендуется использовать отдельные пары ключей для каждой роли или среды (доступ с личной рабочей станции, развёртывание CI/CD, обслуживание базы данных). Это ограничивает последствия компрометации одного ключа и упрощает отзыв без нарушения работы несвязанных систем.

Что произойдёт, если я потеряю закрытый ключ?

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

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

Наиболее распространённые причины: неправильные права доступа к ~/.ssh/ (должны быть 700) или ~/.ssh/authorized_keys (должны быть 600) на сервере; домашний каталог доступен для записи всем пользователям; SELinux или AppArmor блокирует доступ к каталогу .ssh; или PubkeyAuthentication no установлен в /etc/ssh/sshd_config. Запустите ssh -vvv, чтобы точно определить, какой метод аутентификации используется и отклоняется.

Как удалить SSH-ключ с сервера, к которому у меня больше нет доступа?

Если у вас нет другого метода аутентификации, обратитесь в службу поддержки вашего хостинг-провайдера или воспользуйтесь внеполосным консольным доступом (доступен для клиентов VPS и выделенных серверов), чтобы войти и напрямую отредактировать ~/.ssh/authorized_keys. Именно поэтому хранение учётных данных консольного доступа отдельно от SSH-ключей является обязательным операционным требованием.