Вход по SSH-ключам вместо пароля: настройка за 10 минут

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

Как вообще работают SSH-ключи

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

Сегодня рекомендуемый тип ключа - ed25519: он короткий, быстрый и стойкий. Старый RSA тоже работает, но брать его стоит только для совместимости со старым софтом и не короче 4096 бит.

Генерация ключа на своём компьютере

Ключ создаётся на вашей машине, а не на сервере. Откройте терминал (в Windows - PowerShell или Git Bash) и выполните:

ssh-keygen -t ed25519 -C "my-laptop"

Программа спросит, куда сохранить файл (по умолчанию ~/.ssh/id_ed25519 - оставьте так) и предложит задать парольную фразу (passphrase). Не пропускайте её: passphrase шифрует приватный ключ, и даже если файл украдут, воспользоваться им без фразы не смогут. Чтобы не вводить её каждый раз, добавьте ключ в агент:

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

После этого рядом появятся два файла: id_ed25519 (приватный, никому не отдавайте) и id_ed25519.pub (публичный, его и повезём на сервер).

Копируем публичный ключ на сервер

Проще всего воспользоваться утилитой ssh-copy-id - она сама создаст нужную папку и допишет ключ в authorized_keys с правильными правами:

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

Один раз потребуется ввести пароль от сервера - это нормально, мы его пока не отключали. Если ssh-copy-id недоступен (например, в базовом Windows), скопируйте ключ вручную:

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

Права важны: SSH откажется работать с ключами, если папка или файл доступны на запись посторонним. Каталог .ssh должен быть 700, а authorized_keys - 600.

Проверяем вход по ключу до всяких отключений

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

ssh user@203.0.113.10

Если вас пустило без запроса пароля сервера (максимум спросили passphrase от ключа) - всё готово, ключ принят. Только теперь можно переходить к ужесточению настроек.

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

Отключаем вход по паролю и меняем порт

Настройки сервера живут в файле /etc/ssh/sshd_config. Откройте его с правами root:

sudo nano /etc/ssh/sshd_config

Найдите и приведите к такому виду следующие строки (уберите символ комментария # в начале, если он есть):

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password
Port 2222

Смена порта с 22 на нестандартный (например, 2222) не защищает сама по себе, но резко снижает поток автоматических атак ботов в логах. Не забудьте открыть новый порт в фаерволе перед перезапуском:

sudo ufw allow 2222/tcp
sudo systemctl restart ssh

На части систем сервис называется sshd, тогда используйте sudo systemctl restart sshd. Теперь в новом окне проверьте вход уже на новый порт:

ssh -p 2222 user@203.0.113.10

Типичные ошибки и как не потерять доступ

Отключили пароль до проверки ключа. Классика. Сначала убедитесь, что вход по ключу работает, и только потом ставьте PasswordAuthentication no.
Забыли открыть новый порт в фаерволе. После рестарта вы просто не достучитесь до сервера. Всегда открывайте порт до перезапуска SSH.
Неправильные права на .ssh. Если authorized_keys доступен на запись группе или всем, сервер молча игнорирует ключ. Проверьте: 700 на папку, 600 на файл.
Единственный ключ на одном ноутбуке. Сломается диск - и вы отрезаны. Добавьте резервный публичный ключ со второго устройства в authorized_keys заранее.

Если доступ всё же потерян, спасает консоль хостинг-провайдера (VNC или веб-терминал в панели управления): через неё можно временно вернуть PasswordAuthentication yes, зайти и всё поправить. Для диагностики полезно смотреть подробный вывод клиента:

ssh -v -p 2222 user@203.0.113.10

Строки с Offering и Server accepts key покажут, дошёл ли ваш ключ. Настроив вход по ключам один раз, вы получаете и удобство (никаких паролей), и заметно более высокий уровень защиты сервера.

Вернуться в блог