Решение проблемы «WARNING: UNPROTECTED PRIVATE KEY FILE!»

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

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

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

При подключении по SSH используя ключи, вы можете столкнуться с примерно следующей ошибкой:

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

Как показано в сообщении, файл размещён по пути /home/mial/.ssh/id_rsa и имеет разрешения 0644.

Разберёмся, что означает набор цифр 0644. Самый первый символ (ноль) в данном случае нас не интересует. В оставшихся трёх цифрах (644) зашифрованы права доступа к файлу.

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

Эти цифры могут быть в диапазоне 0-7. Они складываются из суммы разрешений, которые также обозначаются цифрами 4, 2, и 1. Цифры означают следующее:

• 4 — чтение
• 2 — запись
• 1 — выполнение
• 0 — отсутствие каких-либо прав доступа на фай

В нашем случае у владельца права доступа обозначаются цифрой 6, её можно получить только из суммы цифр 4 и 2. 4 — это право на чтение, а 2 — это право на запись. Итак, у владельца есть право на чтение и запись.

У группы и у всех остальных пользователей права 4 — то есть только право на чтение.

Наличие всех прав (чтение, запись, выполнение) обозначается цифрой 7.

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

Чтобы исправить эту проблему, достаточно установить такие права доступа для файла с приватным ключом, чтобы его не могли просматривать посторонние.

Приватный ключ подключения по SSH обычно храниться в файле

/.ssh/id_rsa. Поэтому для исправления ошибки «It is required that your private key files are NOT accessible by others. This private key will be ignored.» достаточно выполнить команду:

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

Ошибка SSH подключения WARNING: UNPROTECTED PRIVATE KEY FILE!

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

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

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

При подключении по SSH используя ключи, вы можете столкнуться с примерно следующей ошибкой:

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

Как показано в сообщении, файл размещён по пути /home/alex/.ssh/privat_key и имеет разрешения 0644.

Разберёмся, что означает набор цифр 0644. Самый первый символ (ноль) в данном случае нас не интересует. В оставшихся трёх цифрах (644) зашифрованы права доступа к файлу.

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

Эти цифры могут быть в диапазоне 0-7. Они складываются из суммы разрешений, которые также обозначаются цифрами 4, 2, и 1. Цифры означают следующее:

• 4 — чтение
• 2 — запись
• 1 — выполнение
• 0 — отсутствие каких-либо прав доступа на фай

В нашем случае у владельца права доступа обозначаются цифрой 6, её можно получить только из суммы цифр 4 и 2. 4 — это право на чтение, а 2 — это право на запись. Итак, у владельца есть право на чтение и запись.

У группы и у всех остальных пользователей права 4 — то есть только право на чтение.

Наличие всех прав (чтение, запись, выполнение) обозначается цифрой 7.

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

Чтобы исправить эту проблему, достаточно установить такие права доступа для файла с приватным ключом, чтобы его не могли просматривать посторонние.

Приватный ключ подключения по SSH обычно храниться в файле

/.ssh/privat_key. Поэтому для исправления ошибки «It is required that your private key files are NOT accessible by others. This private key will be ignored.» достаточно выполнить команду:

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

Windows SSH: разрешения для «закрытого ключа» слишком открыты

Я установил OpenSSH 7.6 в Windows 7 для целей тестирования. Клиент и сервер SSH работают нормально, пока я не попытался получить доступ к одной из своих коробок AWS EC2 из этого окна.

Кажется, мне нужно изменить разрешение на файл закрытого ключа. Это можно легко сделать в Unix / Linux с помощью chmod команды.

А как насчет окон?

private-key.ppm скопирован непосредственно из AWS, и я думаю, что разрешение тоже.

Вы находите файл в проводнике Windows, щелкните его правой кнопкой мыши и выберите «Свойства». Перейдите на вкладку «Безопасность» и нажмите «Дополнительно».

Смените владельца на вас, отключите наследование и удалите все разрешения. Затем предоставьте себе «Полный контроль» и сохраните разрешения. Теперь SSH больше не будет жаловаться на разрешение файла, слишком открытое.

Это должно выглядеть так:

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

• GUI:
  • Свойства [Файл] — Безопасность — Дополнительно
    1. Установите владельца на пользователя ключа
    2. Удалите всех пользователей, группы и службы, кроме пользователя ключа , в разделе « Записи разрешений».
    3. Установите для пользователя ключа полный доступ

CLI:

В дополнение к ответу, предоставленному ibug. Так как я использовал систему Ubuntu внутри Windows, чтобы запустить команду SSH. Это все еще не работало. Так я и сделал

и тогда это сработало

У меня была такая же проблема, и, похоже, она связана с версией SSH, которую вы используете.

Когда я бегу ssh -V в обоих местах, я получаю

Итак, когда я запускаю ssh из каталога git / bin, он работает нормально и не жалуется на разрешения, но, запустив ту же командную строку, используя прежнюю установку SSH, он возвращается с этим.

пс. права доступа к файлу — это полный доступ для себя и больше ничего.

Вам нужны только 2 вещи:

1) Отключить наследование

2) Преобразовать унаследованные разрешения в явные разрешения

3) Удалить группу пользователей

4) В итоге пользователи не смогут получить доступ к личным файлам, этого должно быть достаточно для добавления id_rsa.

У меня была похожая проблема, но я был на работе, и у меня нет возможности изменять права доступа к файлам на моем рабочем компьютере. Что вам нужно сделать, это установить WSL и скопировать ключ в скрытый каталог ssh в WSL:

Теперь вы сможете нормально изменять разрешения.

Затем SSH с использованием WSL:

используйте команду ниже на вашем ключе, она работает на Windows

Вы можете использовать icacls в окнах вместо chmod для настройки прав доступа к файлам. Чтобы дать текущему пользователю разрешение на чтение и удалить все остальное,

Это всего лишь скриптовая версия ответа CLI @ JW0914, так что в первую очередь оповестите его. Кроме того, это мой первый скрипт PowerShell, поэтому предложения приветствуются.

Одна строка в CMD может помочь (как описано здесь: https://serverfault.com/a/883338/550334 ), то есть добавление ключа из stdin вместо изменения разрешений:

Чтобы проверить, был ли добавлен ключ:

Скачать с Git для Windows или напрямую.

Он также имеет другие полезные команды Linux, такие как tar и gzip .

Я пользователь Windows, использую bash для Windows и выполнил все шаги, чтобы установить разрешение с помощью графического интерфейса Windows, но он все еще не работает и жалуется:

Я добавил sudo в начале команды ssh, и это просто работает. Надеюсь, что это полезно для других.

Ответ от iBug работает отлично! Вы можете следить за этим и избавиться от этой проблемы.

Но есть несколько вещей, которые необходимо очистить, так как я столкнулся с проблемами при настройке разрешений, и мне понадобилось несколько минут, чтобы выяснить проблему!

После ответа iBug вы удалите все разрешения, но как вы установите для себя разрешение «Полный доступ»? вот где я сначала застрял, так как не знал, как это сделать.

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

Как только закончите с этим,

Нажмите на Add затем нажмите Set a Principal затем введите System и и Administrators и your email addredd в поле внизу, затем нажмите check names .

Он загрузит имя, если пользователь существует. Затем нажмите OK > Тип Allow > Основные разрешения Full Control > Okay

Это установит разрешение «Полный доступ» для СИСТЕМЫ, Администраторов и Вашего Пользователя.

После этого попробуйте ssh, используя этот ключ. Это должно быть решено сейчас.

У меня была та же проблема, и я решил, что с помощью этого метода. Если есть какой-либо пользователь или группа с таким именем, он будет загружен.

Использование windows subsystem for linux для доступа к vagrant машине по ssh, ругается на права доступа к файлу приватного ключа, что можно сделать?

Уточнение, не удается зайти именно с использованием ключа, с паролем нормально захожу.

Решил посмотреть что такое vagrant, параллельно поиграться с windows subsystem for linux, но пока не получается зайти на виртуальную машину по ssh (который для меня тоже темный лес).

С помощью chmod права на файл изменить не удалось.

Подскажите пожалуйста, можно ли заставить ssh игнорировать права на файл ключа или изменить их как то на удовлетворяющие ssh?

• Вопрос задан более трёх лет назад
• 468 просмотров

Петр Иванов: chmod 600 .vagrant/machines/default/virtualbox/private_key

Никакой ошибки не выдается, но права не изменяются

До выделенного жирным можно не читать, не важно. Нда, не думаю что ещё актуально, но вдруг кто то случайно набредёт. Столкнулся со схожей ошибкой, под w10 был включён openssh client(на момент написания данный дополнительный компонент находится в стадии beta, установлен напрямую из винды, параметры/приложения/управление дополнительными компонентами).

Решилось так, я удалил у ключа все унаследованные права доступа(естественно лежит он hdd, раздел которого отформатирован в ntfs) и дал доступ только от имени используемой учётной записи. После этого проблем с использованием больше не наблюдал

WARNING: UNPROTECTED PRIVATE KEY FILE! #3686

Comments

DariusLLL commented Nov 28, 2018

This bug-tracker is monitored by developers and other technical types. We like detail! So please use this form and tell us, concisely but precisely, what’s up. Please fill out ALL THE FIELDS! Issues with missing or incomplete issue templates will be closed.

If you have a feature request, please post to the UserVoice.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to secure@microsoft.com. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from «C:\Windows\minidump».

Please fill out the below information:

Your Windows build number: (Type ver at a Windows Command Prompt)
Microsoft Windows [Version 10.0.17134.407]

What you’re doing and what’s happening: (Copy&paste specific commands and their output, or include screen shots)
dariusl@DARIUS-NAMAI:

/.ssh$ ssh -i dariusl_id_rsa-cert.pub dariusl@g-lb04.arwico.info
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for ‘dariusl_id_rsa-cert.pub’ are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key «dariusl_id_rsa-cert.pub»: bad permissions
dariusl@g-lb04.arwico.info’s password:

What’s wrong / what should be happening instead:
dariusl_id_rsa-cert.pub is a certificate file which is signed on the server
I other words: in WSL ubuntu 18-04 ssh -i expects only private key file.
The same case is working perfectly from Hyper-V Ubuntu VM but not from WSL

If I chmod to 600 — I get wrong key file format. Of course, because dariusl_id_rsa-cert.pub is certificate file.
Thanks
DL

The text was updated successfully, but these errors were encountered: