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

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

1. Что такое SSH-ключи и зачем они нужны

SSH-аутентификация по ключам использует пару криптографических ключей:

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

Как работает аутентификация

Когда вы подключаетесь по SSH с ключом:

1. Сервер проверяет, есть ли ваш публичный ключ в файле ~/.ssh/authorized_keys пользователя.
2. Сервер отправляет случайную задачу, которую можно выполнить только обладателю приватного ключа.
3. Ваш клиент подписывает задачу приватным ключом и отправляет ответ.
4. Если подпись верна — доступ разрешается без пароля.

Приватный ключ и парольная фраза — разные вещи

• Пароль учётной записи — пароль пользователя на сервере (например, admin или root).
• Passphrase приватного ключа — дополнительная защита самого файла ключа. Если ключ украдут, злоумышленник не сможет им воспользоваться без парольной фразы.

2. Проверка наличия SSH-ключей

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

ls -la ~/.ssh

Пример вывода, если ключи уже есть:

total 4
drwx------ 2 user user 4096 Oct 20 10:00 .
drwxr-xr-x 3 user user 4096 Oct 20 09:00 ..
-rw------- 1 user user 3900 Oct 20 10:00 id_ed25519
-rw-r--r-- 1 user user  745 Oct 20 10:00 id_ed25519.pub

• id_ed25519 — приватный ключ (права 600, только чтение для владельца).
• id_ed25519.pub — публичный ключ (его можно копировать на сервер).

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

3. Создание новой пары ключей

Рекомендуемый алгоритм — Ed25519. Он современный, быстрый и безопасный.

Выполните на локальном компьютере:

ssh-keygen -t ed25519 -C "user@client"

Где:

• -t ed25519 — тип ключа (алгоритм Ed25519).
• -C "user@client" — комментарий (обычно имя пользователя и хост, помогает идентифицировать ключ).

Программа запросит:

1. Путь к файлу — нажмите Enter, чтобы использовать стандартный (~/.ssh/id_ed25519), или укажите свой.
2. Passphrase — optional. Если оставите пустым, вход будет происходить без ввода дополнительного пароля. Если зададите — придётся вводить passphrase при каждом использовании ключа (или использовать ssh-agent).

Результат

Создатся два файла:

~/.ssh/id_ed25519        # приватный ключ (не передавайте никому)
~/.ssh/id_ed25519.pub    # публичный ключ (копируйте на сервер)

Когда может понадобиться RSA

Некоторые очень старые системы не поддерживают Ed25519. В этом случае создайте RSA-ключ:

ssh-keygen -t rsa -b 4096 -C "user@client"

Ключ длиной 4096 бит считается надёжным для RSA.

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

Способ 1: ssh-copy-id (рекомендуемый)

Выполните на локальном компьютере:

ssh-copy-id user@server_ip

Пример:

ssh-copy-id admin@192.168.1.100

Если SSH работает на нестандартном порту:

ssh-copy-id -p 2222 admin@192.168.1.100

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

Способ 2: Ручной способ (если ssh-copy-id недоступен)

Выполните на локальном компьютере:

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

Права доступа на сервере

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

Выполните на удалённом сервере (под пользователем, под которым заходите):

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

5. Подключение по SSH-ключу

После копирования ключа подключайтесь без пароля:

ssh user@server_ip

Пример:

ssh admin@192.168.1.100

Подключение через нестандартный порт

ssh -p 2222 user@server_ip

Использование конкретного приватного ключа

Если у вас несколько ключей:

ssh -i ~/.ssh/id_ed25519 user@server_ip

Работа с ssh-agent

Если вы задали passphrase приватному ключу, ssh-agent позволит ввести его один раз за сессию:

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

Настройка ~/.ssh/config с алиасом

Чтобы не помнить IP и порт, создайте на локальном компьютере файл ~/.ssh/config:

Host my-server
    HostName 192.168.1.100
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519

После этого достаточно набрать:

ssh my-server

6. Проверка работоспособности

Откройте новое SSH-подключение (не закрывайте текущее, на случай если что-то пойдёт не так):

ssh user@server_ip

Если вход проходит без запроса пароля — аутентификация по ключу работает.

Диагностика через ssh -v

Если соединение не проходит, используйте подробный вывод:

ssh -v user@server_ip

Ищите строки вроде:

Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:...
Server accepts key: pkalg ssh-ed25519 ...

Если сервер принимает ключ, вы увидите Server accepts key или Authenticated to ... using publickey.

Запрос passphrase не означает ошибку

Если вы задали passphrase при создании ключа, SSH спросит её при подключении. Это не означает, что вход по ключу не работает — это просто дополнительная защита самого файла ключа.

7. Отключение входа по паролю (опционально)

Это необязательный заключительный этап. Выполняйте его только после того, как убедились, что вход по ключу работает в новой сессии, и у вас есть резервный административный доступ (например, через консоль сервера или другой канал).

Проверка текущих настроек

Выполните на удалённом сервере:

sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

Пример вывода:

passwordauthentication yes
kbdinteractiveauthentication yes
permitrootlogin yes

Изменение конфигурации

Отредактируйте файл /etc/ssh/sshd_config (или файл в /etc/ssh/sshd_config.d/, если ваш дистрибутив использует Include):

PasswordAuthentication no
KbdInteractiveAuthentication no

Проверьте конфигурацию перед применением:

sshd -t

Если ошибок нет — перезапустите SSH-службу:

systemctl restart ssh

Или перезагрузите конфигурацию без разрыва соединений:

systemctl reload ssh

Предупреждение

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

Не отключайте парольную аутентификацию автоматически на сервере пользователя — это решение должен принять администратор после проверки.

8. Типичные проблемы и их решение

Permission denied (publickey,password)

Причины:

• Неверные права на ~/.ssh или ~/.ssh/authorized_keys на сервере.
• Публичный ключ скопирован не под тем пользователем.
• На сервере отключена аутентификация по ключу (PubkeyAuthentication no).

Решение: проверьте права (chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys) и настройки sshd_config.

Ключ сохранён не у того пользователя

Убедитесь, что публичный ключ лежит в ~/.ssh/authorized_keys того пользователя, от имени которого вы подключаетесь.

Используется неправильный приватный ключ

Укажите ключ явно:

ssh -i ~/.ssh/id_ed25519 user@server_ip

На сервере запрещена аутентификация по ключу

Проверьте sshd_config:

PubkeyAuthentication yes

Неправильный порт или адрес

Убедитесь, что порт SSH на сервере совпадает с указанным в команде.

Проблемы с ssh-agent

Если ключ не добавился в агент:

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

Диагностика через ssh -vvv

Для максимально подробного вывода:

ssh -vvv user@server_ip

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

• Никогда не копируйте приватный ключ на удалённый сервер. На сервер копируется только публичный ключ.
• Используйте passphrase для защиты приватного ключа, особенно если ключ хранится на ноутбуке или общем компьютере.
• Не публикуйте ключи и не пересылайте их третьим лицам.
• Если ключ скомпрометирован, удалите соответствующую запись из ~/.ssh/authorized_keys на всех серверах и создайте новую пару ключей.
• Для критичных серверов сохраняйте резервный административный доступ (консоль, IPMI, другой администратор).

SSH-аутентификация по ключам значительно защищает от подбора паролей, но не защищает от всех угроз (например, от вредоносного ПО на локальном компьютере, которое может украсть приватный ключ).

10. Краткая памятка

Статья подготовлена для публикации на IT-дневнике blog.nixit.ru.