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

Часть 6 из 12 · Серия «Свой сервер с нуля»

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

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

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

Картина целиком за 30 секунд

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

Шаг 1. Создаём пару ключей

Делается это на вашем компьютере, не на сервере. Откройте терминал (на Windows — PowerShell или Windows Terminal) и введите:

ssh-keygen -t ed25519 -C "ваш_комментарий"

ed25519 — современный и рекомендуемый тип ключа. Если придётся работать с очень старым сервером, который его не понимает, возьмите проверенный временем вариант: ssh-keygen -t rsa -b 4096. В комментарий обычно пишут свою почту или название машины — просто чтобы потом узнать ключ в лицо.

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

В результате появятся два файла. id_ed25519 — приватный ключ, его никому и никогда не показывают и никуда не загружают. id_ed25519.pub с расширением .pub — публичный, вот его и понесём на сервер. Запомните это различие: всё, что заканчивается на .pub, можно отдавать; всё остальное — только ваше.

Шаг 2. Кладём публичный ключ на сервер

Самый простой способ — одна команда:

ssh-copy-id пользователь@адрес_сервера

Она сама подключится, спросит у вас пароль от сервера в последний раз и аккуратно пропишет публичный ключ куда нужно — в файл ~/.ssh/authorized_keys, заодно выставив правильные права на файлы. Этот «в последний раз» — приятный момент: дальше пароль вам больше не понадобится.

На Windows утилиты ssh-copy-id обычно нет. Тогда делаем вручную: открываете файл id_ed25519.pub, копируете его содержимое целиком и добавляете отдельной строкой в файл ~/.ssh/authorized_keys на сервере. Способ тот же, просто руками.

Шаг 3. Проверяем вход

Момент истины. Подключаемся как обычно:

ssh пользователь@адрес_сервера

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

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

Шаг 4. Выключаем вход по паролю

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

Открываете на сервере файл /etc/ssh/sshd_config и приводите две строки к такому виду:

PasswordAuthentication no
PermitRootLogin prohibit-password

Первая запрещает вход по паролю, вторая — вход под root по паролю (ключом — можно). Сохраняете и перезапускаете службу:

sudo systemctl restart ssh

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

Маленькая, но коварная деталь. На свежих системах часть настроек SSH лежит не в основном файле, а в дополнительных, в папке /etc/ssh/sshd_config.d/. Бывает, что там стоит PasswordAuthentication yes, и оно перебивает то, что вы только что прописали. Если пароль упрямо продолжает работать — загляните туда и поправьте.

Если что-то пошло не так

Самая частая ошибка — Permission denied (publickey). Обычно причина в правах на файлы: папка ~/.ssh должна быть доступна только владельцу, как и authorized_keys. Команда ssh-copy-id это делает сама, а вот при ручном копировании права легко перекосить. Проверьте также, что подключаетесь под тем же пользователем, которому клали ключ.

Если умудрились заблокировать себе вход — не паникуйте. Почти у каждого провайдера в панели есть веб-консоль (VNC), через которую можно зайти на сервер в обход SSH и всё починить. А если перед изменениями вы сделали снапшот — откатиться на него дело пары минут. Это и есть та страховка, о которой мы говорили раньше.

Пара правил, чтобы спать спокойно

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

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

Шпаргалка по командам

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

Серия «Свой сервер с нуля»

Полный цикл — от выбора хостинга до рабочего сайта с почтой, Docker и бэкапами. Вы читаете часть 6 из 12.

1. VDS, VPS, хостинг, облако — что это
2. Nginx vs Apache: холивар, который пора закрыть
3. Зачем арендовать сервер, если есть хостинг за 100 ₽
4. SSH для тех, кто боится чёрного экрана
5. Как не запороть сервер в первый день: топ ошибок
6. SSH-ключи за 10 минут: вход без пароля — вы здесь
7. Поднимаем свой сайт на VPS за вечер
8. Ставим WordPress на свой VPS
9. Свой почтовый сервер — героизм или мазохизм?
10. Docker на VPS: спасение или пушка по воробьям
11. Настраиваем домен и SSL, чтобы браузер не ругался
12. Бэкапы, которые реально спасут

← Предыдущая: Как не запороть сервер в первый день: топ ошибок · Следующая: Поднимаем свой сайт на VPS за вечер →