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

Быстрые ссылки

• Что не так с паролями?
• Чем SSH‑ключи безопаснее?
• Проверьте доступ к удалённому компьютеру
• Создание пары SSH‑ключей
• Установка публичного ключа
• Подключение с помощью SSH‑ключей
• Нет паролей, но выше безопасность
• Когда SSH‑ключи не помогают
• Альтернативы и улучшения
• Шаблон: чек‑лист и пошаговый плейбук
• Инцидентный план при компрометации ключа

Краткий словарь

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

Что не так с паролями?

Пароли — самый распространённый метод аутентификации. Но у них есть слабые места:

• Человеческий фактор: люди выбирают простые пароли или повторно используют их.
• Фишинг и социальная инженерия: атакующий выманит пароль у пользователя.
• Брутфорс и перебор: слабые пароли легко подобрать автоматизировано.
• Утечки и хранение: базы паролей могут быть скомпрометированы.

Пароли обычно служат для одного кусочка доказательства: «я знаю секрет». SSH‑ключи добавляют криптографическую проверку и делают этот процесс надёжнее.

Чем SSH‑ключи безопаснее?

SSH‑ключи работают парами: публичный и приватный ключ. Коротко:

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

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

Дополнительно:

• Типы ключей: RSA (устаревающий при коротких битах), ECDSA, Ed25519 (рекомендуем для новых ключей: компактный и быстрый).
• SSH‑агент (ssh‑agent) позволяет один раз ввести фразу‑пароль и затем автоматически использовать приватный ключ в течение сессии.

Проверьте доступ к удалённому компьютеру

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

Пример: у пользователя dave есть логин на компьютере howtogeek. Он подключается к серверу Sulaco так:

ssh dave@sulaco

Введите пароль, убедитесь, что подключение проходит, затем выполните:

exit

Если пароль работает — можно переходить к установке ключей. Если нет — устраните проблему с учётной записью или сетью (SSH‑порт, файрвол, доступ по имени/адресу).

Создание пары SSH‑ключей

Инструкции проверены на Ubuntu, Fedora и Manjaro. Обычно уже установлен OpenSSH.

Сгенерируйте ключ командой:

ssh-keygen

В процессе вас попросят указать путь для сохранения ключа. Нажмите Enter для значения по умолчанию (обычно ~/.ssh/id_rsa или ~/.ssh/id_ed25519). Затем введите фразу‑пароль (passphrase). Рекомендуем:

• Фраза‑пароль из 3–4 несвязанных слов или длинная уникальная строка.
• Никогда не оставляйте приватный ключ без фразы, если хотите сохранить высокий уровень безопасности.

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

Установка публичного ключа на сервер

Самый простой способ — утилита ssh‑copy‑id. Она копирует публичный ключ в файл ~/.ssh/authorized_keys на сервере.

ssh-copy-id dave@sulaco

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

Альтернативы, если ssh‑copy‑id недоступна:

• Скопировать вручную содержимое ~/.ssh/id_*.pub и добавить его в ~/.ssh/authorized_keys на сервере (через временный пароль или другой канал).
• Использовать Ansible, cloud‑init или средства провайдера для массового развёртывания ключей.

Важно: убедитесь, что права доступа к папке ~/.ssh и файлу authorized_keys корректны:

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

Если права выставлены неправильно, SSH сервер может игнорировать авторизованные ключи.

Подключение с помощью SSH‑ключей

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

ssh dave@sulaco

Теперь SSH клиент запросит фразу‑пароль к приватному ключу (если она установлена). После ввода фразы вы получите доступ без ввода пароля учётной записи.

Советы по удобству и безопасности:

• ssh‑agent: запустите ssh‑agent и добавьте ключ через ssh‑add, чтобы не вводить фразу каждый раз.
• Графические оболочки часто предлагают «Automatically unlock this key whenever I’m logged in». Это удобно, но снижает безопасность на устройствах с доступом третьих лиц.
• Для автоматизированных задач (CI/CD) используйте отдельные ключи без фразы, но с ограничениями на сервере (например, ограничение команд в authorized_keys).

Нет паролей, но повышенная безопасность

Преимущества:

• Устойчивость к фишингу и перебору паролей.
• Возможность централизованного управления ключами.
• Лёгкость интеграции с аппаратными токенами (см. ниже).

Недостатки / компромиссы:

• Если приватный ключ скомпрометирован и не отозван — угроза серьёзная.
• Требуется дисциплина: резервное копирование ключей, использование фраз‑паролей, управление доступом.

Когда SSH‑ключи не помогают (примеры и ограничения)

• Физический доступ к машине: если злоумышленник получил доступ к вашей рабочей сессии, агент может быть доступен.
• Компрометация локального хоста: если ваш компьютер заражён и приватный ключ украден, фраза‑пароль может быть перехвачена кейлоггером.
• Неправильная настройка сервера: если права на ~/.ssh неверны или authorized_keys не прочитан, подключение по ключам не сработает.
• Атакующий получает бэкап приватного ключа из облака или резервной копии без шифрования.

Альтернативы и улучшения

• Двухфакторная аутентификация (2FA) поверх SSH: PAM‑модули для OTP (например, Google Authenticator).
• Аппаратные ключи FIDO2/WebAuthn (например, YubiKey) для SSH: более высокая стойкость, приватный ключ хранится в аппаратном модуле.
• Централизованное управление SSH‑ключами: Vault‑решения, LDAP, SSO‑интеграции.
• Ограничение доступа через forced‑command, from=«IP», и другие параметры в authorized_keys.

План действий: чек‑лист перед миграцией на ключи

1. Убедиться, что парольный доступ по SSH работает для всех нужных учётных записей.
2. Сгенерировать пару ключей для каждого пользователя.
3. Защитить приватные ключи фразой‑паролем.
4. Установить публичные ключи на сервер(а) и проверить подключение.
5. Настроить ssh‑agent/ключевые менеджеры по необходимости.
6. Испытать откат: ещё раз проверить вход по паролю на случай проблем.
7. После успешного тестирования: на сервере отключить аутентификацию по паролю (PasswordAuthentication no).
8. Ввести процедуру ротации ключей и резервного копирования.

Плейбук: пошаговая инструкция для администратора

1. Сгенерировать ключ локально: ssh‑keygen -t ed25519 -C “user@workstation”.
2. Копировать ключ: ssh‑copy‑id user@host.
3. Проверить подключение: ssh user@host.
4. Прописать права: chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys.
5. (Опционально) В /etc/ssh/sshd_config: установить PasswordAuthentication no; PermitRootLogin prohibit‑password.
6. Перезапустить sshd: sudo systemctl restart sshd.
7. Мониторить попытки входа в логах /var/log/auth.log или journalctl.

Инцидентный план: если приватный ключ скомпрометирован

1. Немедленно отозвать ключы, удалив соответствующие строки из ~/.ssh/authorized_keys на всех серверах.
2. Сгенерировать новую пару ключей и развернуть публичный ключ заново.
3. Проверить логи на предмет подозрительной активности (время входов, IP‑адреса).
4. Если ключ использовался для автоматизации, обновить CI/CD токены и секреты.
5. Оповестить команду безопасности и произвести пост‑инцидентный разбор.

Тесты и критерии приёмки

• Тест 1: пользователь подключается с новым ключом и входит без запроса пароля учётной записи.
• Тест 2: попытка входа с удалённого хоста без соответствующего ключа отклоняется.
• Тест 3: при отключении PasswordAuthentication доступ по паролю блокируется, а доступ по ключу остаётся.

Критерии приёмки:

• Все производственные доступы проходят тесты 1–3.
• Документирована процедура ротации ключей и резервного копирования.
• Команда прошла инструктаж по безопасному хранению приватных ключей.

Конфигурация сервера: распространённые параметры

В /etc/ssh/sshd_config обратите внимание на:

• PasswordAuthentication no — отключает вход по паролю.
• PubkeyAuthentication yes — включает проверку по ключам.
• AuthorizedKeysFile .ssh/authorized_keys — путь к файлу с публичными ключами.
• PermitRootLogin prohibit-password — запрет прямого входа root по паролю.

После изменений перезапустите службу sshd.

Советы по совместимости и миграции

• Старые серверы могут не поддерживать Ed25519. В таких случаях используйте RSA с длиной не менее 3072 бит.
• Для массового развёртывания используйте Ansible, chef, puppet или cloud‑init.
• Документируйте соответствие «ключ ↔ пользователь ↔ сервер» и храните журналы доступа.

Безопасность и конфиденциальность

• Храните приватные ключи в зашифрованных контейнерах или с помощью менеджеров ключей.
• Не отправляйте приватный ключ по электронной почте и не храните его в общедоступных репозиториях.
• В случаях обработки персональных данных проверьте внутренние политики и требования GDPR: доступ к системам должен быть регламентирован и задокументирован.

Когда вероятнее всего что‑то пойдёт не так — галерея крайних случаев

• Пропущена точка в authorized_keys (ошибка формата) — SSH игнорирует ключ.
• Неправильные права на ~/.ssh — сервер отклоняет авторизацию ключом.
• Автоматизация использует ключ без фразы и этот ключ попадает в общий репозиторий.
• Пользователь потерял доступ к приватному ключу и нет резервной копии.

Примеры команд и сниппеты (шпаргалка)

Генерация Ed25519 с комментарием:

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

Добавление ключа в ssh‑agent:

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

Копирование ключа вручную через ssh:

cat ~/.ssh/id_ed25519.pub | ssh user@host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Проверка журналов на сервере:

journalctl -u sshd --since "1 hour ago"
# или
sudo tail -n 200 /var/log/auth.log

Решение типичных проблем (траблшутинг)

• Ошибка «Permission denied (publickey)» — проверьте права, правильность ключа в authorized_keys и формат файла.
• Агент не хранит ключ — убедитесь, что ssh‑agent запущен и ключ добавлен через ssh‑add.
• После изменения sshd_config подключение пропало — всегда держите одну активную сессию до проверки новых настроек или используйте консоль провайдера.

Ментальные модели и эвристики

• «Ключи — как ключи от дома»: публичный ключ — это как метка на замке, приватный — сам ключ. Не давайте его никому.
• Делайте отдельные ключи для разных ролей: работа, серверы CI, автоматизация.
• Минимизируйте время действия ключей: регулярно ротируйте и отзывайте устаревшие.

Короткое резюме

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

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