Серверы и VDS

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

Эдгар Косулин 5 мин чтения

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

Содержание

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

Напомню в одной фразе, зачем это нужно. Пароль можно подобрать перебором, а 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, мелочь, которая делает работу с ключами по-настоящему бесшовной.

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

Шаг Команда
Создать ключ ssh-keygen -t ed25519 -C "комментарий"
Скопировать на сервер ssh-copy-id пользователь@адрес
Проверить вход ssh пользователь@адрес
Отключить пароли правка PasswordAuthentication no в /etc/ssh/sshd_config
Перезапустить SSH sudo systemctl restart ssh

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

Серия

Свой сервер с нуля

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

Безопасность

Поделиться: Telegram ВКонтакте

Новые статьи и разборы — в канале Siteko: Telegram MAX

Подписчикам: +30 дней к пробному хостингу, клиентам: +150 ₽ на баланс

Пошаговые инструкции по нашим услугам — в базе знаний

Ещё по теме

Ищете папку сайта в файловом менеджере и не находите. Как по DNS понять, на каком сервере сайт, найти его папку на VDS и почему нужного файла может не быть.

«Сервер в бою», часть 16

Сервер магазина пропал целиком. Как мы сделали резерв с репликой базы, почему облачный балансировщик не подошёл и что стоит проверить у себя.

«Сервер в бою», часть 15

Серверы и VDS 8 мин чтения

Переезд на другой VPS без даунтайма: чек-лист миграции

Поводов переехать у VPS-владельца за жизнь накапливается достаточно: у соседнего провайдера вдвое дешевле и втрое быстрее диски; старый тариф стал тесен; провайдер начал чудить; или (помните шестую статью?) вы выбрали «путь Б»: вместо release-upgrade на живую поднять свежую систему рядом. Повод есть...

«Сервер в бою», часть 14