Windows ssh warning unprotected private key file

Обновлено 07.04.2022

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз мы с вами разобрали ошибку, что для устройства не установлены драйверы (код 28). Идем далее и сегодня хочу с вами поделиться практическими знаниями, по устранению ошибки в open ssh клиенте Windows. Звучит она вот так, что на секретный ключ id_rca bad permissions (WARNING: UNPROTECTED PRIVATE KEY FILE, Permission denied publickey). В результате подключиться не получается. Давайте переходить от слов к делу.

Как выглядит ошибка id_rsa bad permissions

В командной строке Windows при попытке подключения выскакивает ошибка:

Как устранить ошибку Permission denied (publickey)

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

Используем скрипт PowerShell

Запустите в режиме администратора оснастку PowerShell ISE и запустите в нем такой скрипт.

Иногда, данный скрипт все же не всех удалят пользователей из ACL, так, что если опять получаете ошибку, то зайдите и проверьте через графический интерфейс.

Редактирование ACL через графический интерфейс

Тут все просто, переходите в расположение файла:

Щелкаем по файлу правым кликом, из контекстного меню выбираем пункт свойства и переходим на вкладку «Безопасность«. Нажмите кнопку «Дополнительно (Advanced)«

Отключаем наследование и сохраняем текущие разрешения «Преобразовать унаследованные разрешения в явные разрешения данного объекта (Convert inherited permission into explicit permissions on this object«.

Далее если вы не являетесь текущим владельцем данного файла, то сделайте себя им и так же удалите потом всех кроме себя в данном списке доступа.

Сохраняем все, после этого у вас должна пропасть ошибка «id_rsa»: bad permissions» и «Permission denied (publickey)».

Используем скрипт командной строки

Во первых вам необходимо создать bat-файл. После чего запустите командную строку от имени администратора и запустите созданный ранее bat-файл.

На этом все. Мы рассмотрели три метода позволяющих исправить ошибки «id_rsa»: bad permissions» и «Permission denied (publickey)» при попытке установить ssh соединение через OpenSSH в Windows. С вами был Иван Сёмин, автор и создатель IT проекта Pyatilistni.org.

Various OpenSSH resource files are integral to secure working of both server and client stacks. Here we discuss how to protect these resources, how OpenSSH for Windows enforces permission checks and individual case studies on how to fix any permission related issues.

Improper file permissions will likely result in a broken configuration (OpenSSH fails to work). Here, you’ll find icacls based commands to fix such issues.

2 fundamental reasons leading to the differences between how these permission checks work on Unix vs Windows:

• SuperUser on Unix maps to either System (SY) or AdministratorsGroup (AG) on Windows.
• Permission controlling in Windows is more granular than in Unix.

Its important to understand the distinction between «AdministratorsGroup» and an admin user. A logged on admin user would typically run processes in non-elevated mode. Even though an admin user is part of AG, these non-elevated processes do not have authority to access resources that are locked only to AG.

Any misconfigured permissions would manifest as an attention seeking log entry. Ex. if a private key is not protected, you’ll see the following:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'ssh_host_dsa_key' are too open.

Server side resources

Host private key files

Host keys represent host’s identity. To prevent unauthorized access to these files, host keys need to be owned by SY or AG. No other user should have access to host key files. Following is a misconfigured host private key because ‘otheruser’ owns it and has access to the key.

PS C:>(get-acl .ssh_host_dsa_key).owner
otheruser
PS C:>icacls .ssh_host_dsa_key
ssh_host_dsa_key   NT AUTHORITYSYSTEM:(F)
                   BUILTINAdministrators:(F)
                   otheruser:(R) 

Steps to fix these permissions

PS C:>icacls .ssh_host_dsa_key /setowner system
PS C:>icacls .ssh_host_dsa_key /remove otheruser

At this point, you could do the following to replicate these permissions onto other host keys

PS C:>get-acl .ssh_host_dsa_key | Set-Acl ssh_host*key

authorized_keys

authorized_keys is an user associated file that represents a list of authorized public keys that could be used for (key-based) user authentication. Unauthorized access to this file compromises the associated user’s account. This file should not be owned by, nor provide access to any other user.
Following is a misconfigured authorized key because

• ‘otheruser1’ has access to the file (through inheritance)
• ‘otheruser2’ has access to this file (explicit permission).

PS C:>(get-acl .usersthisuser.sshauthorized_keys).owner
thisuser
PS C:>icacls .usersthisuser.sshauthorized_keys
ssh_host_dsa_key   BUILTINAdministrators:(F)
                   thisuser:(F) 
                   otheruser1:(IR)
                   otheruser2:(R)

Steps to fix these permissions — remove inheritance and inherited permissions

PS C:>icacls .usersthisuser.sshauthorized_keys /inheritance:r
PS C:>icacls .usersthisuser.sshauthorized_keys /remove otheruser2

administrators_authorized_keys

Default location for authorized keys file for users in administrators group is
%programdata%sshadministrators_authorized_keys
This file should only be accessible by SYSTEM and Administrators group.

Steps to fix permissions on this file:

PS C:>icacls administrators_authorized_keys /inheritance:r
PS C:>icacls administrators_authorized_keys /grant SYSTEM:`(F`)
PS C:>icacls administrators_authorized_keys /grant BUILTINAdministrators:`(F`)

Client side resources

User private key files

User’s private keys are user’s credentials. To prevent unauthorized access to these files, private keys need to be owned by the user and no other user should have access to user’s key files.

ssh_config

User level default ssh_config is located in user’s profile (~/.ssh/config). This has similar restrictions as the user’s private keys described above.

Решение проблемы «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. Цифры означают следующее:

В нашем случае у владельца права доступа обозначаются цифрой 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 сможет выполнить подключение.

Источник

OpenSSH using private key on Windows («Unprotected private key file» error)

I am attempting to do a simple connection to a SSH server using OpenSSH for Windows using a private key, and am met with this:

On Linux, this is fixed with a simple chmod 600 on the private key file, however Windows does not have an equivalent method.

This sounds like something that should be pretty easy, but I am completely unable to find any reasonable solution to it. Is there a way to either add the private key directly without going through a file, or to skip this privacy check? Or am I missing something else entierly?

6 Answers 6

You can use icacls in Windows instead of chmod to adjust file permission. To give the current user read permission and remove everything else (Which will allow openssh to work), this works nicely:

In PowerShell, you can get icacls to work by wrapping the command in a call to cmd.exe

You locate the file in Windows Explorer, right-click on it then select «Properties». Navigate to the «Security» tab and click «Advanced».

Change the owner to you, disable inheritance and delete all permissions. Then grant yourself «Full control» and save the permissions. Now SSH won’t complain about file permission too open anymore.

I did it on Windows 10 and it fixed the issue as you can see in the image as well.

You should change the owner of the file(which contains the private key)to your username with full access. and then remove the other usernames that have access to that file.

right-click on the file which contains the private key and clicks on properties and then Security tab> Advanced by clicking on the change button you can change the owner to your username. (if you don’t know the name of your username run: «echo %USERNAME%» in command prompt.) Change>Advanced. >Find Now

remove all Permission entries except the one you just added

click on Disable inheritance> Convert inherited permissions. then remove all Permission entries except the one you just added.

Источник

Fixing “UNPROTECTED KEY FILE” when using SSH or Ansible inside WSL

Published by Schakko on January 10, 2020 January 10, 2020

Inside a native Linux environment the error UNPROTECTED KEY FILE always means that the permissions of private key file are way too open. The error usually occurs if you are trying to connect with SSH and a private key to a remote host. As Ansible does also use SSH, you may also receive the error:

As you can see, the permissions 0777 (read, write and execute permissions for owner, group membership and others) are not allowed. Fixing this is trivial as you just have to change the permissions to 600:

If you are executing the chmod command inside a WSL (Windows Subsystem for Linux) container, e.g. the default Ubuntu distribution, you may notice that the permission does not have changed and are still the same:

The reason for this is that your Windows volume is probable mounted without any metadata. When you are showing a list of your mounted devices, the metadata attribute is missing:

Without the metadata attribute, Linux is not able to determine the correct file permissions inside WSL.

The temporary solution for this problem has Microsoft described. You need to mount your volume with the -o metadata option:

After re-mounting the volume, mount will show that the drive has been mounted with the metadata attribute:

Make the changes persistent

With a restart of your WSL instance, the volume wouldn’t get loaded with the metadata attribute. To make the changes persistent, you can either edit /etc/fstab or add an entry to your /etc/wsl.conf file. If the file does not exist, you can just create it.

The changes are only applied after the WSL container has been terminated. It is not sufficient to just close the WSL terminal:

I am asking you for a donation.

You liked the content or this article has helped and reduced the amount of time you have struggled with this issue? Please donate a few bucks so I can keep going with solving challenges.

Источник

Getting «Warning: unprotected private key file!» error message while attempting to import SSH key [closed]

Want to improve this question? Update the question so it’s on-topic for Stack Overflow.

Can someone explain this to me please and what I can do to sort out my permissions issue. It seems to be stopping me from getting the authenticity of host heroku and fixing my keys issues.

6 Answers 6

I would recommend you to re create a set of keys using

for a more secure system. Else changing the permissions to something less open would do.

To change permissions, use

Simply reset permissions to your key files to defaults

Just change the permission of the /.ssh/id_rsa file to 400

This won’t make others or from any group members to modify the file.

If you are using WSL, you can copy file.pem to

Done, try again with your ssh-add

If you are using WSL, first, you can copy file.pem to

Done, try again with ssh-add

You should change the owner of the file(which contains the private key)to your username with full access. and then remove the other usernames that have access to that file.

Right Click on the file which contains the private key and clicks on properties and then Security tab> Advanced by clicking on the change button you can change the owner to your username. (if you don’t know the name of your username run: «echo %USERNAME%» in command prompt.) Change>Advanced. >Find Now

Remove all Permission entries except the one you just added

click on Disable inheritance> Convert inherited permissions. then remove all Permission entries except the one you just added.

Источник

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

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

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

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

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

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

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

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

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

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

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

Итак, когда я запускаю 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 или напрямую.

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

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

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

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

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

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

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

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

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

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

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

Источник