Openssh windows плохой владелец или разрешения
Я установил openssh для Windows, и когда я запускаю ssh localhost, я получаю
Bad owner or permissions on C:\Users\gary/.ssh/config
Я посмотрел на эти 2 вопроса https://superuser.com/questions/348694/bad-owner-or-permissions-error-using-cygwins-ssh-exe и https://serverfault.com/questions/253313/ssh-returns-bad-owner-or-permissions-on-ssh-config, но ни один из ответов у меня не работает. sshd работает как служба от имени пользователя локальной системы. Я использовал chmod 0600 C:\Users\gary\.ssh\config и chown gary C:\Users\gary\.ssh\config. Я также очистил ACL, запустив setfacl -b C:\Users\gary\.ssh\config, а затем снова chmod 0600 C:\Users\gary\.ssh\config. Я также попытался сменить владельца на SYSTEM и получил ту же ошибку.
Я не знаю, что еще делать, что-то не так с моей настройкой? У меня также установлен git, который установил mingw, я удалил ssh и sshd из своей установки git, чтобы они не были на моем пути.
Другие команды, которые я выполнил:
icacls "C:\Users\gary\.ssh\config" /setowner garychown -R gary:1049089 C:\Users\gary\.ssh
ls -la C:\Users\gary\.ssh\config показывает
-rw-r--r-- 1 gary 1049089 229 Jan 3 14:43 'C:\Users\gary.ssh\config'
он продолжает показывать это даже после смены владельца на SYSTEM, но в свойствах файла в проводнике файлов он показывает SYSTEM как владельца
этот блог может быть полезным
Сегодня та же проблема. Я пробовал много разных вещей и, наконец, у меня получилось. 1. отключил наследование для папки .ssh и удалил все разрешения, 2. добавили администраторов с разрешениями обратно 3. переименовали имя моего компьютера, чтобы оно отличалось от имени пользователя. все еще использую windows openssh, а не git.
Ответы 18
У меня сработало изменение клиента ssh с C: \ Windows \ System32 \ OpenSSH \ ssh.exe на C: \ Program Files \ Git \ usr \ bin \ ssh.exe.
Было бы лучше, если бы вы также сказали шаги.
Спасибо за подсказку. Я решил проблему, добавив C: \ Program Files \ Git \ usr \ bin в системную переменную Path и убедившись, что она выше (раньше) % SYSTEMROOT% \ System32 \ OpenSSH. К сожалению, я не могу использовать Git ssh со службой Windows ssh-агент. Тогда я расшифрую все свои закрытые ключи.
Я решил это, используя GitBash вместо Cygwin.
У меня такая же проблема после переустановки Windows. И легко исправить, просто изменив права доступа к файлу на
SYSTEM & Administrators - Full Control
[your username] - Modify & as Owner
Примечание:
- Я все еще использую Встроенный SSH-клиент Windows 10
C:\Windows\System32\OpenSSH\ssh.exeи вообще не использую cygwin
Вышеупомянутое сработало для меня, но не сработало, если я заменил имя пользователя на OWNER в строке разрешений, где Fery дал ему права на изменение. Полный контроль работает над разрешениями.
Это сработало для меня (OpenSSH-Win32 в Windows 10) после удаления наследования и всех других разрешений и добавления только себя с полным доступом.
Предоставление пользователю полного контроля над файлом и / или удаление наследования не помогает. Думаю, я просто поменяю SSH-клиент, раз уж у меня установлен Git Bash :)
Просто прокомментирую этот ответ для SEO немного подробнее, так как его было трудно найти. Мы использовали Composer для Windows 10 версии 1.9.3. Этот ответ решил проблему «НЕЗАЩИЩЕННЫЙ ЧАСТНЫЙ КЛЮЧ-ФАЙЛ» и «Плохой владелец или разрешения» при попытке обновления из нашего собственного частного репозитория BitBucket.
Это сработало для меня. Я все еще использую Win 10 1703 и использую вручную установленную версию Win32-OpenSSH.
Я не уверен, какая версия Windows у вас установлена, но, поскольку это недавняя версия, я бы предположил, что это Windows 10. Недавно я обнаружил, что клиент OpenSSH установлен по умолчанию с апрельского обновления 2018 года. Затем я обнаружил, что у меня есть два экземпляра OpenSSH: тот, который я установил сам, и тот, который мне дала Windows. Удаление того, что я установил, вызвало сообщение об ошибке, которое вы описываете.
Решение, которое сработало для меня, заключалось в том, чтобы удалить установленный пользователем OpenSSH, а также папку C:\Users\username\.ssh и позволить Windows 10 OpenSSH создать папку при следующем запуске команды. У меня не было конфигурации, которую я боялся потерять, но если вы это сделаете, я бы посоветовал скопировать и вставить куда-нибудь содержимое файлов, а затем восстановить их.
Надеюсь это поможет!
Проверка разрешений, предоставленных самим ssh.exe после удаления папки .ssh, и их применение к остальным файлам решила проблему для меня.
Для всех, у кого все еще есть проблемы после применения владельца + модификации (плюс полный контроль для администраторов): у меня это не сработало. Затем я увидел решение по удалению всех остальных пользователей (включая всех администраторов), которое тоже не помогло.
Это сработало для меня:
- оставьте Систему и Администраторов на месте, с полным контролем, как предложено выше
- оставьте самого пользователя на месте, как владельца, с изменением, как предложено выше
- однако удалите любого другого пользователя или группу. Возможно, сначала нужно перейти на расширенный, чтобы отключить наследование прав
после того, как я удалил пользователя с правами администратора, который был добавлен Windows после входа в мою папку (через поле UAC), это снова сработало для меня.
Надеюсь, это поможет всем, кто столкнется с этой конкретной проблемой :-)
Используйте FixUserFilePermissions.ps1 для исправления разрешений файлов на стороне клиента - ключей и файлов конфигурации текущего пользователя.
git clone [email protected]:PowerShell/openssh-portable.git
cd openssh-portable/contrib/win32/openssh
.\FixUserFilePermissions.ps1 -Confirm:$false
Мне пришлось клонировать репо, cd в /openssh-portable/contrib/win32/openssh, а затем выполнить указанную выше команду. Намного проще, чем настраивать свойства и разрешения файлов Windows.
Если пользователь находится в административной группе, просто сохраните конфигурацию в c: \ programdata \ ssh \ ssh_config вместо% USERPROFILE% .ssh \ config, будет работать
Это было решение, которое я в конечном итоге использовал. У компьютера было то же имя, что и у пользователя, и это означало, что мне не нужно было его менять.
Проблема, похоже, из-за того, что файлы принадлежат / имеют разрешение более чем для одного пользователя.
1- Перейдите в папку ./ssh и для файлов config и id_rsa. Из свойств -> Безопасность -> Дополнительно:
2- Убедитесь, что пользователь, с которым вы вошли в систему, является единственным пользователем.
Это начало появляться сразу после того, как я создал другого пользователя с правами администратора, и эта учетная запись начала наследовать доступ к моей папке .ssh.
Вам не нужно вообще изменять свои разрешения.
Просто зайдите в .ssh, щелкните правой кнопкой мыши «Свойства», «Безопасность», «Дополнительно». ОТКЛЮЧИТЕ НАСЛЕДОВАНИЕ, затем щелкните пользователя-администратора (того, кто не вы) и удалите его. Применять. Сделанный.
Похоже, именно так и произошло со мной. Я бы создал еще одну учетную запись пользователя в системе для тестирования. И у него был доступ. Как только я удалил этого пользователя из доступа к папке .ssh, все заработало.
Я пробовал это, но это не решило проблему для меня
Большое спасибо ! Это сработало для меня. Итак, ниже была моя среда, и я надеюсь, что кто-то сочтет это полезным. - WSL 1.0 под управлением Ubuntu 20 на машине с Windows 10 - .ssh / config файл не читался бродягой и постоянно вызывал проблемы с разрешениями. - применил вышеуказанные настройки, и vagrant ssh отлично справился с почтовым приложением
Когда вы отключаете наследование, вас спросят, хотите ли вы скопировать текущие унаследованные права доступа. Выберите «Да», а затем продолжите, удалив другого пользователя, как описано выше.
Подробное обновление 2021 года. Еще нужно удалить наследование. Использование: владелец -> Полный контроль. Администратор -> Изменить. Удалите любые другие. Обратите внимание, что если вы откроете файл, он может снова изменить разрешения, в зависимости от используемого программного обеспечения.
Без смены группы или чего-то еще, первый ответ правильный. Как?
- удалить openssh из Win10 в Настройки
- добавьте путь к git ssh.exe на ваш
Path
Для меня это было исправлено запуском конфигурации chmod 0644 в ~ / .ssh / при запуске WSL.
Для тех, кто все еще борется с этим, обратите внимание на это: https://github.com/PowerShell/openssh-portable/pull/418. Так было со мной. Оказывается, ваш компьютер должен называться иначе, чем ваше имя пользователя ... ?♂️ Вероятно, это будет скоро исправлено в будущих обновлениях, потому что исправление попало в фиксацию.
Итак, еще раз:, если имя вашего компьютера совпадает с именем пользователя, и вы до сих пор не устранили эту проблему с диалоговым окном разрешений, возможно, переименование вашего компьютера может помочь.
Хотя эта ссылка может дать ответ на вопрос, лучше включить сюда основные части ответа и предоставить ссылку для справки. Ответы, содержащие только ссылки, могут стать недействительными, если связанная страница изменится.
Большое спасибо. Это исправило это для меня
Совершенно верно. Мое имя пользователя и имя компьютера совпали. Переименование на другие имена устранило проблему. Спасибо
Спасибо, это решило проблему для меня! Проблема до сих пор не устранена, мне пришлось изменить имя компьютера.
Для меня это было исправлено запуском конфигурации chmod 0644 в ~ / .ssh /. Ранее он был установлен на 755, что вызывало "Неверный владелец или разрешения на /home/home/.ssh/config"
Да!! Он также работает под Windows 10 (выполняется через Git Bush).
Я попробовал все вышеперечисленные решения и, к сожалению, все еще не могу исправить эту проблему. Я почти уверен, что разрешение моей конфигурации ssh правильное, это было проверено графическим интерфейсом пользователя Explore и командами Get-Acl.
Затем я наконец нашел способ решить эту проблему:
удалите всю папку .ssh, затем откройте PowerShell и введите ssh localhost. Он создаст для вас новую папку .ssh, после чего вы сможете применить указанные выше настройки разрешений (для меня я сделал только одно: отключил наследование).
Так что, если другие решения не работают для вас, возможно, вы можете попробовать это. Надеюсь, это поможет.
PS: не забудьте сделать резервную копию своей старой папки .ssh перед ее удалением.
У меня была эта проблема, и никакое изменение разрешений или отключение наследования в файле конфигурации не помогло бы ее исправить. Оказалось, что ему не нравится, что имя моего компьютера и имя пользователя совпадают, поэтому я переименовал свой компьютер, разрешил open ssh воссоздать файл конфигурации, и теперь разрешения верны. Наверное, это было плохой идеей для начала, черт возьми.
Пожалуйста, сосредоточьтесь на ответе на вопрос без добавления субъективного описания
- Переименуйте файл config во что-нибудь вроде config2
- Откройте этот файл с помощью блокнота
- Сохранить как конфигурацию (оригинальное название)
Это сработало для меня.
Я предполагаю, что это было вызвано неправильным выражением пути.
Bad owner or permissions on C:\Users\gary/.ssh/config
/.ssh должен быть \.ssh. Поэтому я пытаюсь использовать git bash (инструмент терминала при установке git в системе Windows) для запуска команды ssh. Это реально работает. Но я действительно не знаю, вызвано ли это той причиной, о которой я догадывался.
Я удалил C:\Users\user/.ssh/config и перезапустил свой материал, и все заработало.
Однако, если у вас есть что-то ценное, сначала сделайте резервную копию, на всякий случай!
На сервере Windows это связано с проблемой разрешения. Необходимо запретить другим пользователям доступ к следующим папкам
.ssh - папка
Щелкните правой кнопкой мыши по этой папке -> выберите «Предоставить доступ» -> нажмите «Удалить доступ». Щелкните правой кнопкой мыши по этой папке -> выберите «Свойства» -> «Ценные бумаги» -> Нажмите «Изменить разрешения» - удалите других пользователей, кроме идентификатора, в который вы вошли.
Повторите тот же процесс для папки, в которой находится файл .pem. (Примечание: храните файл .pem в отдельной папке)
У меня такая же проблема сегодня впервые после обновления Windows. Я также использую cmder, и "vagrant ssh" вызывает у меня ту же ошибку. Я узнал (из переменной среды
PATH), что клиентssh, который использовал бродяга, был клиентом изC:\WINDOWS\System32\OpenSSH. Поэтому мне просто нужно было сначала добавить путь к моему собственному клиентуssh- проблема решена. Надеюсь это поможет.