# SSH-ключи вместо пароля на VPS: как настроить и отключить вход по паролю

> Создаём ключ ed25519, копируем открытую часть на VPS, проверяем вход без пароля и только после этого отключаем PasswordAuthentication.

- Рубрика: Гайды по играм
- Игра: VPS
- Опубликовано: 2026-11-13T14:30:00+03:00
- Обновлено: 2026-11-13T14:30:00+03:00
- Адрес: https://blog.egnetwork.ru/vps-ssh-klyuchi
- Автор: Команда EGN

## Коротко

SSH-ключ — это пара файлов: закрытый остаётся у вас, открытый уходит на сервер. Вход по ключу защищён лучше пароля, потому что его почти невозможно подобрать перебором. Создайте ключ командой `ssh-keygen -t ed25519`, скопируйте открытую часть на VPS через `ssh-copy-id`, проверьте вход и только после этого отключите вход по паролю директивой `PasswordAuthentication no`.

Порядок важен. Если отключить пароль, не проверив ключ, вы можете потерять доступ к серверу.

## Зачем нужны ключи

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

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

## Шаг 1. Создаём ключ на своём компьютере

На компьютере с Linux или macOS выполните:

```bash
ssh-keygen -t ed25519 -C "ноутбук"
```

Тип `ed25519` — современный и короткий, его поддерживают все актуальные версии OpenSSH. Флаг `-C` добавляет комментарий, по которому потом удобно понять, с какого устройства ключ. Программа спросит путь для сохранения. Оставьте путь по умолчанию `~/.ssh/id_ed25519`. Затем задайте парольную фразу. Она защищает закрытый ключ, если его кто-то получит. Пустую фразу ставить не стоит, если ноутбук не зашифрован.

![Создание ключа ed25519](https://blog.egnetwork.ru/media/657)

В результате появятся два файла:

- `~/.ssh/id_ed25519` — закрытый ключ. Его не отправляйте никому и никуда не загружайте.
- `~/.ssh/id_ed25519.pub` — открытый ключ. Его можно передавать и класть на сервер.

В Windows 10 и 11 команда та же, выполняется в PowerShell. Файлы окажутся в `C:\Users\<имя>\.ssh\`. Парольную фразу лучше задать и там.

## Шаг 2. Копируем открытый ключ на VPS

Самый простой способ — команда `ssh-copy-id`:

```bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10
```

Она попросит пароль root один раз и добавит открытый ключ в файл `~/.ssh/authorized_keys` на сервере, создав каталог `~/.ssh` с закрытыми правами, если его нет. В Windows команды `ssh-copy-id` нет, там ключ копируют так (в PowerShell):

```powershell
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh root@203.0.113.10 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
```

![Копирование открытого ключа на VPS](https://blog.egnetwork.ru/media/658)

Теперь проверьте вход:

```bash
ssh root@203.0.113.10
```

Если пароль больше не спрашивают, ключ работает. Если спросили, значит, ключ не подхватился: проверьте, что вы копировали именно `.pub`, а не закрытый файл.

## Шаг 3. Отключаем вход по паролю

Только после успешного входа по ключу откройте настройки SSH на сервере. Главное правило sshd: если директива встречается несколько раз, действует первое найденное значение. В Ubuntu 24.04 основной `/etc/ssh/sshd_config` подключает файлы из `/etc/ssh/sshd_config.d/` в самом начале, и читаются они по алфавиту.

На новом VPS EGN при создании системы записывается файл `/etc/ssh/sshd_config.d/00-egn-access.conf` с двумя строками: `PasswordAuthentication yes` и `PermitRootLogin yes`. Именно благодаря ему вы смогли войти по паролю из письма. Из-за порядка чтения новый файл с другим именем, например `00-egn-keys.conf`, окажется после него и ничего не изменит. Поэтому сначала посмотрите, где что задано:

```bash
sudo grep -ri -E "PasswordAuthentication|PermitRootLogin" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
```

Если в списке есть `00-egn-access.conf`, правьте его:

```bash
sudo nano /etc/ssh/sshd_config.d/00-egn-access.conf
```

Приведите содержимое к такому виду:

```text
PasswordAuthentication no
PermitRootLogin prohibit-password
```

Вторая строка разрешает root вход только по ключу. Если вы завели отдельного пользователя с `sudo`, можно поставить `PermitRootLogin no`, но делайте это, только когда вход под ним проверен. Если файла `00-egn-access.conf` нет (например, вы переустановили систему или образ другой), создайте файл `/etc/ssh/sshd_config.d/00-keys.conf` с теми же строками.

Проверьте синтаксис и примените настройки:

```bash
sudo sshd -t && sudo systemctl reload ssh
```

Команда `sshd -t` проверяет конфигурацию без применения. Если ошибок нет, она молча завершится, и тогда `reload` перечитает настройки. Если ошибка есть, `reload` не выполнится, а текущая сессия останется рабочей.

Проверить итоговое значение можно так:

```bash
sudo sshd -T | grep -i passwordauthentication
```

Должно вывести `passwordauthentication no`.

![Отключение входа по паролю](https://blog.egnetwork.ru/media/659)

> [!WARNING] Проверьте вход в новом окне до перезагрузки
> Откройте новый терминал и войдите по ключу, пока старая сессия ещё открыта. Если вход не работает, исправьте файл ключа в старой сессии. Не закрывайте её, пока не убедитесь в обратном.

## Примеры: несколько ключей и ключ для скриптов

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

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

```bash
ssh-keygen -t ed25519 -C "deploy-script" -f ~/.ssh/deploy_ed25519
```

## Частые ошибки

**Permission denied (publickey).** Сервер не принимает ключ. Причины: ключ не добавлен в `authorized_keys`, неверные права на каталог `~/.ssh` или файл `authorized_keys`, либо ключ от другого компьютера. Права должны быть такими: каталог `700`, файл `600`.

**Пароль отключили, а ключ не работает.** Именно поэтому порядок такой: сначала проверьте ключ, потом отключайте пароль. Если всё же застряли, откройте в карточке услуги вкладку «Консоль» (VNC): вход на консоли идёт мимо sshd, поэтому логин `root` и пароль из письма там продолжают работать. Исправьте настройки и вернитесь в SSH.

**Закрытый ключ попал в репозиторий или чат.** Если это случилось, немедленно удалите открытый ключ из `authorized_keys` на всех серверах, создайте новый и выпустите его заново. Закрытый ключ, который попал на публичный ресурс, считается скомпрометированным.

**Ключи с правами 644 на файле закрытого ключа.** OpenSSH откажется его использовать и покажет предупреждение о слишком открытых правах. Выставьте `chmod 600 ~/.ssh/id_ed25519`.

## Таблица: симптом, причина и решение

| Симптом | Причина | Решение |
|---|---|---|
| `Permission denied (publickey)` | Ключ не добавлен в `~/.ssh/authorized_keys` на сервере | Добавьте открытый ключ командой из шага 2 и проверьте файл командой `cat ~/.ssh/authorized_keys` |
| `Permission denied (publickey)` после правок | Неверные права на `~/.ssh` или `authorized_keys` | Выполните `chmod 700 ~/.ssh` и `chmod 600 ~/.ssh/authorized_keys` на сервере |
| `WARNING: UNPROTECTED PRIVATE KEY FILE!` | Закрытый ключ доступен другим пользователям | На компьютере: `chmod 600 ~/.ssh/id_ed25519` |
| Пароль по-прежнему спрашивают после отключения | Первое значение директивы задано в другом файле, обычно `00-egn-access.conf` | Выполните `sudo sshd -T \| grep -i passwordauthentication`, найдите источник командой `grep` из шага 3 и правьте именно его |
| `sshd -t` выдаёт ошибку | Опечатка в директиве | Исправьте файл и повторите проверку. Пока ошибка есть, `reload` не выполняйте |
| После `reload` вход не работает | Ключ был не тем, а пароль уже отключён | Войдите через вкладку «Консоль» в карточке услуги, верните `PasswordAuthentication yes` и поправьте ключ |

Порядок файлов стоит запомнить отдельно. Облачные образы Ubuntu иногда содержат собственный `50-cloud-init.conf` с `PasswordAuthentication`, а EGN добавляет `00-egn-access.conf`. Если вы правите только основной `sshd_config`, изменение не сработает: sshd берёт первое найденное значение, а файлы из `sshd_config.d` читаются раньше. Поэтому проверка через `sshd -T` и `grep` по обоим местам обязательна.

## Альтернатива: скопировать ключ вручную

Если `ssh-copy-id` не установлен, одна команда с перенаправлением делает то же самое:

```bash
cat ~/.ssh/id_ed25519.pub | ssh root@203.0.113.10 'mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys'
```

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

## Пример: несколько серверов в одном конфиге

Для удобства заведите алиасы в `~/.ssh/config`, как в статье про первый вход. Ключ можно указать явно, если на компьютере несколько ключей:

```text
Host egn-vps
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host deploy-bot
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/deploy_ed25519
    IdentitiesOnly yes
```

Параметр `IdentitiesOnly yes` говорит клиенту пробовать только указанный ключ. Без него клиент перебирает все ключи в агенте, и сервер может отключить соединение после нескольких неудачных попыток.

## Как проверить, что пароль действительно отключён

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

```bash
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password root@203.0.113.10
```

Правильный ответ — отказ без запроса пароля, примерно такой:

```text
root@203.0.113.10: Permission denied (publickey).
```

Если вы видите запрос пароля, настройка не применилась: проверьте файлы в `/etc/ssh/sshd_config.d/` и выполните `sudo sshd -T | grep -i passwordauthentication`. Пока значение не `no`, не считайте защиту включённой.

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

## Пример: ключ для сайта и ключ для себя

Представьте, что на VPS живут сайт и Telegram-бот. Вам нужен доступ себе, а боту — только для выкладки. Разумно завести два отдельных ключа и два отдельных пользователя на сервере: например, `admin` с `sudo` и `deploy` без `sudo`, который может только перезапускать свой сервис. Тогда ключ бота, если он утечёт, не даст права на всю систему.

Создать ключ для бота можно так:

```bash
ssh-keygen -t ed25519 -C "bot-deploy" -f ~/.ssh/bot_ed25519 -N ""
```

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

## Вопросы и ответы

### Нужен ли пароль к ключу?

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

### Что выбрать: ed25519 или RSA?

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

### Можно ли вернуть вход по паролю?

Да. Верните `PasswordAuthentication yes` в том же файле, где вы его меняли, и выполните `sudo sshd -t && sudo systemctl reload ssh`. Но лучше оставить вход по ключам: пароль root в любом случае остаётся рабочим на VNC-консоли в кабинете.

## Итог

Ключ ed25519 — лучший способ входа на VPS: он надёжнее пароля и удобнее для автоматизации. Создайте ключ, скопируйте открытую часть через `ssh-copy-id`, проверьте вход и только потом отключите `PasswordAuthentication`. Дальше переходите к защите сервера: [Базовая защита VPS: ufw, fail2ban и обновления](https://blog.egnetwork.ru/vps-bazovaya-zashchita). Основы входа описаны в статье [VPS: первые шаги и вход по SSH](https://blog.egnetwork.ru/vps-pervye-shagi-ssh).

Сервер под VPS за пару минут — [egnetwork.ru](https://egnetwork.ru/)

---

Материал EGN (blog.egnetwork.ru), обновлено 13 ноября 2026; при цитировании указывайте ссылку.