Как настроить вход на сервер по SSH-ключам

Коротко: четыре шага

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

1. Создать пару ключей на своем компьютере.
2. Положить публичный ключ на сервер.
3. Проверить вход по ключу в новой сессии.
4. Отключить вход по паролю.

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

Шаг 1. Генерация ключа

ssh-keygen -t ed25519 -C "you@laptop"

• ed25519 — современный тип ключа: короткий, быстрый и надежный. RSA используйте только если старая система не поддерживает ed25519.
• Задайте passphrase. Без нее любой, кто получит файл ключа, получит и доступ к серверам.
• Появятся два файла: ~/.ssh/id_ed25519 (приватный, никому не передавать) и ~/.ssh/id_ed25519.pub (публичный, его можно копировать куда угодно).

Шаг 2. Копирование ключа на сервер

Самый простой способ:

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

Если ssh-copy-id недоступна (например, в Windows), добавьте содержимое .pub-файла в конец ~/.ssh/authorized_keys на сервере вручную. Права важны — при слишком открытых правах sshd проигнорирует ключ:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Шаг 3. Проверка

Откройте новый терминал и выполните ssh user@server. Если сервер не спросил пароль от аккаунта (только passphrase ключа, если она задана), все работает. Для диагностики используйте ssh -v user@server — в выводе видно, какие ключи предлагаются и почему отклоняются.

Шаг 4. Отключение входа по паролю

В файле /etc/ssh/sshd_config (или в отдельном файле в /etc/ssh/sshd_config.d/) задайте:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

Проверьте синтаксис и перезапустите службу:

sudo sshd -t && sudo systemctl reload ssh

На некоторых дистрибутивах служба называется sshd. Учтите, что файлы в sshd_config.d/ могут переопределять основной конфиг — проверьте их, если настройка не применилась.

ssh config для нескольких серверов

Чтобы не помнить IP, порты и имена пользователей, заведите ~/.ssh/config:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host staging
    HostName 203.0.113.20
    User deploy

Теперь достаточно ssh prod. Опция IdentitiesOnly заставляет клиент предлагать только указанный ключ — это помогает, когда ключей много и сервер отбивает соединение из-за слишком большого числа попыток.

Agent forwarding: удобно, но рискованно

ssh-agent хранит расшифрованные ключи в памяти, чтобы не вводить passphrase постоянно. Опция ForwardAgent yes пробрасывает агент на удаленный сервер — например, чтобы делать git pull оттуда вашим ключом.

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

• не включайте ForwardAgent глобально, только для конкретных доверенных хостов;
• для прыжков через промежуточный сервер используйте ProxyJump (ssh -J bastion target) — он не отдает агент промежуточному хосту;
• для деплоя с сервера лучше выдать отдельный deploy key с правами только на чтение репозитория.

Частые ошибки

• Отключили пароли, не проверив ключ, и потеряли доступ.
• Неверные права на ~/.ssh или домашнюю папку.
• Один ключ без passphrase на всех серверах и у всех разработчиков.
• Не удаляют ключи уволившихся сотрудников из authorized_keys.