Ошибка SSH UNPROTECTED PRIVATE KEY FILE: слишком открытые права на ключ

Что сделать прямо сейчас

1. На Mac и Linux выполните chmod 600 ~/.ssh/id_ed25519. Вместо id_ed25519 подставьте имя файла из сообщения.
2. В Windows уберите доступ других пользователей командой icacls — она в шаге 3.
3. Подключитесь снова.

Если имя файла в сообщении заканчивается на .pub, права менять не нужно — см. раздел «Если в сообщении файл с .pub на конце».

Вместо ВАШ_IP подставьте адрес своего сервера из панели провайдера. В примерах вывода стоит адрес 203.0.113.10 — у вас будет свой IP.

Что значит это предупреждение

Полностью сообщение выглядит так:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/anna/.ssh/id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/anna/.ssh/id_ed25519": bad permissions
ivan@203.0.113.10: Permission denied (publickey).

ssh проверяет права на файл закрытого ключа. Если файл ваш, а открыть его могут и другие пользователи компьютера, ssh такой ключ не использует — об этом строка This private key will be ignored. В строке Permissions стоят сами права: 0644 значит, что читать файл может кто угодно.

Дальше ssh пробует другие ключи и способы входа. Если ни один не подошёл, в конце появляется Permission denied.

Подходят права 600 — читать и менять файл может только владелец — и 400 — только читать, тоже только владелец. Права, при которых доступ есть у группы или у всех остальных, например 644 или 640, ssh отвергает.

В Windows в строке Permissions нет цифр: Permissions for '…' are too open. Смысл тот же.

Как права на ключ становятся слишком широкими:

• ключ скопировали с другого компьютера или из архива, и файл получил обычные права, как у документа;
• ключ сохранили вручную — вставили текст ключа в новый файл в редакторе;
• после -i указали открытый ключ — файл с .pub на конце;
• в Windows файл унаследовал от папки доступ для других пользователей — например, ключ лежит в «Загрузках» или на рабочем столе.

Шаг 1. Найдите файл в сообщении

Имя файла стоит в строке Permissions в кавычках и повторяется в строке Load key. В примере выше это /Users/anna/.ssh/id_ed25519. В командах ниже — ключ id_ed25519 в папке .ssh. Если у вас файл называется иначе или лежит в другой папке, подставьте путь из сообщения.

Если имя заканчивается на .pub, сразу переходите к разделу «Если в сообщении файл с .pub на конце».

Шаг 2. Исправьте права на Mac и Linux

Откройте терминал (как это сделать) и выполните:

chmod 600 ~/.ssh/id_ed25519

Команда оставляет право читать и менять файл только владельцу — вам. Проверьте:

ls -l ~/.ssh/id_ed25519

Строка должна начинаться с -rw-------: буквы r и w только в первой тройке, дальше одни дефисы. На Mac сразу после них может стоять знак @ — на ssh он не влияет.

Если ключ лежит в другом месте, укажите путь к нему, например chmod 600 ~/Downloads/mykey.

Шаг 3. Исправьте права в Windows

Команды для Windows ниже — для «Командной строки»: нажмите Win+R, напечатайте cmd и нажмите Enter (подробнее). Если строка в окне начинается с PS, это PowerShell: напечатайте cmd, нажмите Enter и продолжайте в том же окне.

icacls "%USERPROFILE%\.ssh\id_ed25519" /inheritance:r /grant:r "%USERNAME%:F"

/inheritance:r убирает права, которые файл унаследовал от папки. /grant:r "%USERNAME%:F" даёт полный доступ вам: вместо %USERNAME% Windows сама подставит ваше имя пользователя. Если ключ лежит в другом месте, замените путь в кавычках.

Проверьте результат:

icacls "%USERPROFILE%\.ssh\id_ed25519"

После пути к файлу команда перечисляет, у кого есть доступ. Должна остаться одна запись — ваше имя (перед ним может стоять имя компьютера) и (F), полный доступ. Если остались другие имена, уберите каждое:

icacls "%USERPROFILE%\.ssh\id_ed25519" /remove "ИМЯ"

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

Если в сообщении файл с .pub на конце

Файл с .pub — открытый ключ. Его кладут на сервер. А после -i и в строке IdentityFile указывают закрытый ключ — тот же файл без .pub. Если указать .pub, ssh попробует прочитать его как закрытый ключ, и у файла с обычными правами 644 появится то же предупреждение:

Permissions 0644 for '/Users/anna/.ssh/id_ed25519.pub' are too open.
Load key "/Users/anna/.ssh/id_ed25519.pub": bad permissions

Исправьте команду — уберите .pub:

ssh -i ~/.ssh/id_ed25519 root@ВАШ_IP

Права на файл .pub не трогайте. Если сузить их до 600, предупреждение исчезнет, но войти всё равно не получится: ssh ответит Load key "…": invalid format — открытый ключ не заменяет закрытый.

Как проверить

Подключитесь снова:

ssh root@ВАШ_IP

Предупреждения быть не должно. Если у ключа есть кодовая фраза, ssh спросит её — это фраза от ключа, а не пароль сервера. Если теперь появилось только Permission denied (publickey), права в порядке, а сервер не принял ключ — см. Permission denied (publickey).

Похожие ошибки

Источники

• man ssh — раздел FILES: закрытый ключ не должен быть доступен другим.
• Win32-OpenSSH: права на файлы в Windows — требования к закрытым ключам пользователя.
• icacls — справка Microsoft — параметры /inheritance, /grant и /remove.
• Исходный код OpenSSH — проверка прав на файл ключа и тексты сообщений.

Сверено 9 октября 2026 года.

Что почитать дальше

• Как подключиться к VPS по SSH — как создать ключ и войти по нему.
• Permission denied (publickey) — если сервер не принимает ключ.
• Load key: invalid format — если ssh не может прочитать ключ.
• Как открыть терминал — если вы ни разу не запускали команды.