Как настроить SSH: генерация ключей и запрет входа по паролю

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

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

На вашем компьютере выполните команду ssh-keygen. Она предложит выбрать тип ключа и место сохранения. Современные версии по умолчанию создают надёжные варианты; для новых ключей обычно выбирают Ed25519 командой ssh-keygen -t ed25519. Затем программа спросит парольную фразу. Её лучше задать: она шифрует закрытый ключ на диске.

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

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

Затем откройте новое окно терминала и подключитесь: ssh пользователь@адрес. Если всё сделано правильно, вход произойдёт без запроса пароля от сервера, а при парольной фразе система запросит именно её, чаще всего один раз за сеанс благодаря агенту ключей.

Пока новое соединение по ключу не проверено, пароль не отключайте. Иначе ошибка оставит вас за дверью. Убедитесь в работе ключа, оставьте старую сессию открытой и лишь затем правьте конфигурацию сервера SSH, обычно файл sshd_config в системном каталоге настроек.

Найдите параметр PasswordAuthentication и задайте значение no. При желании запретите прямой вход администратора параметром PermitRootLogin. После правки проверьте синтаксис командой sshd -t, затем перезагрузите службу. Не закрывая старую сессию, откройте новую и проверьте, что вход по ключу работает, а по паролю отклоняется.

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

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

Смена стандартного порта снижает шум в журналах, но защитой не является. Не забудьте разрешить новый порт в межсетевом экране до перезапуска службы.

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

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

Агент ключей хранит расшифрованный ключ в памяти на время сеанса, поэтому парольную фразу не придётся вводить перед каждым подключением. Добавьте ключ командой ssh-add и проверьте список загруженных ключей. Агент лучше не пробрасывать на чужие серверы без необходимости: тот, у кого есть права на удалённой машине, получит возможность пользоваться вашими ключами, пока вы подключены.