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

#Что означает ошибка

WARNING: UNPROTECTED PRIVATE KEY FILE! Permissions 0644 for key are too open — SSH отказывается использовать закрытый ключ, который доступен другим пользователям. Ключ должен читаться только владельцем (права 600), а каталог ~/.ssh — иметь 700.

Это проверка безопасности клиента, а не ошибка сервера.

Исправляется командой chmod, а в Windows — настройкой ACL.

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

#Причины и решения

#Пошаговое решение

1. Проверьте права ключаНа компьютере, с которого выполняется SSH, найдите имя приватного ключа в предупреждении и откройте терминал в этом каталоге. На Linux/macOS выполните ls -l ~/.ssh/id_ed25519 с фактическим именем; приватный ключ должен быть доступен только владельцу. Не путайте его с файлом .pub, который является открытым ключом.
2. Установите chmod 600 на ключНа Linux/macOS выполните chmod 700 ~/.ssh и chmod 600 ~/.ssh/id_ed25519, подставив имя своего ключа. Эти команды не изменяют данные ключа, но ограничивают его чтение и изменение; убедитесь через ls -l, что у файла стоят права -rw-------, затем повторите SSH-подключение.
3. Для Windows сбросьте ACLВ Windows OpenSSH права задаются списками ACL, а не chmod. Откройте «Свойства → Безопасность → Дополнительно» приватного ключа и проверьте, что доступ имеют ваша учётная запись и необходимые системные субъекты; перед удалением унаследованных разрешений сохраните их. Командой icacls пользуйтесь только для точечного изменения конкретного файла и с пониманием своей SID.
4. Скопируйте ключ из /mnt/c в домашнюю папку WSLЕсли SSH запускается внутри WSL, а ключ расположен на /mnt/c/..., файловая система Windows может отображать права иначе. Создайте в домашнем каталоге Linux ~/.ssh, скопируйте ключ туда с соблюдением правил безопасности, затем задайте chmod 600 уже на копии и используйте путь Linux. Удалять оригинал необязательно до проверки подключения.
5. Проверьте формат ключаЕсли предупреждение исчезло, но сервер продолжает отклонять ключ, проверьте, что приватный файл начинается с -----BEGIN OPENSSH PRIVATE KEY----- или иного поддерживаемого формата без публикации содержимого; для проверки соответствия открытого ключа используйте ssh-keygen -y -f путь_к_ключу. Не отправляйте приватный ключ в службу поддержки или онлайн-проверки.
6. Только владелец читает и пишет

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Только владелец читает и пишет.

   chmod 600 ~/.ssh/id_rsa

#Linux, macOS, WSL

Выполните chmod 600 ~/.ssh/id_ed25519 и chmod 700 ~/.ssh. Проверьте: ls -l ~/.ssh. Ключ должен принадлежать вашему пользователю: sudo chown $USER:$USER ~/.ssh/id_ed25519. Публичные ключи (.pub) могут иметь 644. В WSL ключи, лежащие на диске Windows (/mnt/c/...), показывают права 777: скопируйте ключ в домашнюю папку WSL (cp /mnt/c/Users/me/key ~/.ssh/ && chmod 600 ~/.ssh/key).

#Windows (OpenSSH)

Откройте PowerShell и сбросьте наследование: icacls $env:USERPROFILE\.ssh\id_ed25519 /inheritance:r затем icacls $env:USERPROFILE\.ssh\id_ed25519 /grant:r "$($env:USERNAME):(R)". Другие пользователи и группы (Users, Authenticated Users) должны быть удалены из ACL. Проверьте: icacls $env:USERPROFILE\.ssh\id_ed25519. Для PuTTY используйте формат .ppk (PuTTYgen), к нему такие требования не применяются.

#Прочее

Проверьте формат ключа: файл должен начинаться с -----BEGIN OPENSSH PRIVATE KEY-----; для ошибки invalid format пересохраните ключ без лишних пробелов и с окончаниями строк LF. Если ключ скомпрометирован (был открыт другим), замените его: ssh-keygen -t ed25519, добавьте новый публичный ключ на сервер и удалите старый из authorized_keys. Для Git используйте тот же порядок прав.