Недавно я не смог клонировать или нажать на github, и я пытаюсь найти основную причину.
Это на окнах
У меня есть cygwin + git, а также msysgit.
Msysgit был установлен со следующими параметрами:
- OpenSSH
- Использовать Git из командной строки Windows
Это дает мне 4 окружения, чтобы попытаться использовать git в:
- Приглашение Windows cmd
- Powershell
- Git Bash
- Cygwin
Каким-то образом мне удалось попасть в такое положение, когда при попытке клонировать репозиторий с помощью msysgit, cmd.exe или Powershell я получаю следующую ошибку:
> Initialized empty Git repository in
> C:/sandbox/SomeProject/.git/
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @ WARNING: UNPROTECTED PRIVATE KEY FILE! @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Permissions 0644 for
> '/c/Users/Ben/.ssh/id_rsa' are too
> open. It is recommended that your
> private key files are NOT accessible
> by others. This private key will be
> ignored. bad permissions: ignore key:
> /c/Users/Ben/.ssh/id_rsa Permission
> denied (publickey). fatal: The remote
> end hung up unexpectedly
Это использует папку .ssh в моей папке c: \ users \ ben \, которая используется msysgit. Я подозреваю, что Cygwin работает, потому что папка .ssh находится в другом месте, но я не уверен, почему
В Git Bash я проверяю разрешения:
$ ls -l -a ~/.ssh
Что дает мне:
drwxr-xr-x 2 Ben Administ 0 Oct 12 13:09 .
drwxr-xr-x 34 Ben Administ 8192 Oct 12 13:15 ..
-rw-r--r-- 1 Ben Administ 1743 Oct 12 12:36 id_rsa
-rw-r--r-- 1 Ben Administ 399 Oct 12 12:36 id_rsa.pub
-rw-r--r-- 1 Ben Administ 407 Oct 12 13:09 known_hosts
Эти разрешения явно слишком расслаблены. Как они попали таким образом, я понятия не имею.
Я могу попытаться изменить их ...
$ chmod -v -R 600 ~/.ssh
что говорит мне:
mode of `.ssh' changed to 0600 (rw-------)
mode of `.ssh/id_rsa' changed to 0600 (rw-------)
mode of `.ssh/id_rsa.pub' changed to 0600 (rw-------)
mode of `.ssh/known_hosts' changed to 0600 (rw-------)
Но, похоже, не имеет никакого эффекта. Я все еще получаю ту же ошибку, и делаю
$ ls -l -a ~/.ssh
дает те же разрешения, что и раньше.
ОБНОВИТЬ:
Я попытался исправить разрешения для этих файлов в cygwin, и cygwin правильно сообщает о своих разрешениях, gitbash не: alt text http://cdn.cloudfiles.mosso.com/c54102/app7962031255448924.jpg
Любые идеи о том, как я могу действительно исправить эти разрешения?
Ответы:
Вы изменили разрешения для всего каталога, что, я согласен, со Splash, является плохой идеей. Если вы помните, каковы исходные разрешения для каталога, я попытался бы установить их обратно, а затем сделать следующее
внутри папки .ssh. Это установит для файла id_rsa значение rwx (чтение, запись, выполнение) только для владельца (вас) и нулевой доступ для всех остальных.
Если вы не можете вспомнить, каковы исходные настройки, добавьте нового пользователя и создайте набор ключей SSH для этого пользователя, создав тем самым новую папку .ssh, которая будет иметь разрешения по умолчанию. Вы можете использовать эту новую папку .ssh в качестве справочной информации о разрешениях для сброса вашей папки .ssh и файлов в.
Если это не сработает, я попробую удалить msysgit, удалить ВСЕ папки .ssh на компьютере (просто для безопасности), затем переустановить msysgit с нужными настройками и попробовать начать заново (хотя я думаю, что вы сказали мне) Вы уже пробовали это).
Отредактировано: также только что нашел эту ссылку через Google - Исправление "ПРЕДУПРЕЖДЕНИЕ: НЕЗАКОННЫЙ ФАЙЛ ЧАСТНОГО КЛЮЧА!" в Linux Хотя он нацелен на linux, он может помочь, так как мы говорим о разрешениях liunx и тому подобном.
источник
-rwx------
. То, что вы показываете, не правильно, если вы правильно выполнили команду chmod.В cygwin's chmod есть ошибка, обратитесь к:
/superuser/397288/using-cygwin-in-windows-8-chmod-600-does-not-work-as-expected
источник
None
. (Я предполагаю, что это стандартная процедура, когда группа не была явно определена). Это изменение явной группыUsers
предположительно позволило cygwin разделять разрешения, и я мог бы наконец установить 600 вместо автоматического 660.chmod 600
git, я бы пожаловался, что мои разрешения остались0660
. Исправление владения группой заставит chown примениться корректно.Для систем * nix очевидным решением является
chmod 600 id_rsa
решением ofc, но в Windows 7 мне пришлось некоторое время ударить головой о стену, но потом я нашел волшебное решение:Перейдите в раздел «Мой компьютер» / «Щелкните правой кнопкой мыши» / «Свойства» / «Дополнительные параметры системы» / «Переменные среды» и УДАЛИТЕ переменную (возможно, из системной и пользовательской среды):
CYGWIN
По сути, это недостаток в mingw32, используемом бинарным git windows, видя все файлы 644 и все папки 755 всегда. Удаление переменной среды не меняет это поведение, но, по-видимому, говорит ssh.exe игнорировать проблему. Если вы устанавливаете надлежащие права доступа к своему id_rsa через настройки безопасности проводников (на самом деле нет необходимости иметь там другого пользователя, кроме вашего, не «всех», не «администраторов», не «системы». Никто. Только вы) , вы все равно будете в безопасности.
Теперь, почему mingw32, отличная от cygwin система, будет использовать любую переменную окружения CYGWIN, мне не понятно. Похоже, ошибка для меня.
источник
Я на XP, и это позволило Git Bash общаться с Github (после большого разочарования):
c:\cygwin\bin\cyg*
(~ 50 файлов) вc:\Program Files\Git\bin\
c:\cygwin\bin\ssh.exe
вc:\Program Files\Git\bin\
(перезапись)Создайте файл,
c:\Documents and Settings\<username>\.ssh\config
содержащий:(необязательно) Используйте,
ssh -v git@github
чтобы увидеть отлаженное соединение.Справочная информация: общая проблема представляет собой сочетание этих двух:
источник
c:\Documents and Settings\<username>\.ssh\config
так как вы заменилиc:\Program Files\Git\bin\ssh.exe
наc:\cygwin\bin\ssh.exe
. Правильно ?LogLevel DEBUG
в файл .ssh \ config, чтобы получить отладочный вывод процесса ssh.exe, запущенного git.exe.Для Windows 7 используется Git, найденный здесь (он использует MinGW, а не Cygwin):
источник
Итак, вот как я на самом деле принудительно изменил свои файлы Windows в отношении самих разрешений на Win7: найдите свой ключ ssh в проводнике Windows: C: \ Users [your_user_name_here] .ssh \ id_rsa
Щелкните правой кнопкой мыши файл> Свойства> вкладка «Безопасность»> кнопка «Дополнительно»> «Изменить права доступа».
Теперь удалите всех, кто не является вашим именем пользователя. Это включает в себя администраторов и пользователей системы. На этом этапе вы можете получить диалог о наследовании разрешений - выберите опцию, которая НЕ наследует - так как мы хотим изменить только этот файл.
Нажмите OK и сохраните, пока не будет сделано.
Я боролся с этим в течение нескольких дней, потому что мои окна не будут изменять права доступа к файлам из командной строки. Таким образом, это также делается на самом деле - вместо использования захватывающих обходных путей, которые могут иметь странные последствия.
источник
Изменение прав доступа к файлам из свойств, отключение наследования и запуск chmod 400 не работали для меня. Разрешения для моего файла закрытого ключа были:
Потом я заметил, что группа была None, поэтому я просто побежал
Тогда я мог бы успешно изменить разрешения с помощью chmod 400 и выполнить команду git push.
источник
ДЛЯ ПОЛЬЗОВАТЕЛЕЙ MAC:
Измените настройки вашего файла пары ключей, набрав это в терминале:
(убедитесь, что вы находитесь в правильном каталоге или пути к имени файла в команде правильно).
источник
Я решаю это работает:
Я надеюсь помочь. Удачи.
источник
После недавнего изучения этой проблемы, и это был один из лучших результатов Google, я подумал, что смогу смириться с простой работой, описанной в обсуждении здесь: http://code.google.com/p/msysgit/issues/detail?id = 261 # c40
Просто включает перезапись mysys ssh.exe с помощью cygwin ssh.exe
источник
У меня была такая же проблема на Windows XP совсем недавно. Я попытался выполнить chmod 700 в моем файле ~ / .ssh / id_rsa, но он не сработал. Когда я посмотрел на разрешения с помощью ls -l в ~ / .ssh / id_rsa, я увидел, что мои эффективные разрешения все еще были 644.
Потом я вспомнил, что разрешения Windows также наследуют разрешения от папок, и папка все еще была открыта для всех. Решением может быть также установка разрешений для папки, но я думаю, что лучшим способом было бы сказать системе игнорировать наследование для этого файла. Это можно сделать, используя расширенную опцию на вкладке безопасности в свойствах файла и сняв флажок «наследовать от родительских прав ...»
Это может быть полезно для других с такой же проблемой.
источник
Я сейчас играю с Git 1.6.5 и не могу повторить ваши настройки:
chmod не изменяет права доступа к файлам для моих ключей.
Окружающая среда:
Обновление: Git 1.6.5.1 тоже работает.
источник
Это особенно сложная проблема в Windows, где недостаточно просто правильно смоделировать файлы. Вы должны настроить свою среду.
На Windows это работало для меня:
Установите Cygwin.
Замените msysgit ssh.exe на cygwin's ssh.exe.
Используя cygwin bash, chmod 600 - файл закрытого ключа, который для меня был "id_rsa".
Если это все еще не работает, перейдите в Панель управления -> Свойства системы -> Дополнительно -> Переменные среды и добавьте следующую переменную среды. Затем повторите шаг 3.
Значение переменной
CYGWIN sbmntsec
источник
Я смог исправить это, выполнив две вещи, хотя вам может не потребоваться выполнить шаг 1.
скопируйте из cygwin ssh.exe и все файлы cyg * .dll в каталог bin Git (это может быть необязательно, но это шаг, который я предпринял, но это само по себе не помогло)
выполните шаги из: http://zylstra.wordpress.com/2008/08/29/overcome-herokus-permission-denied-publickey-problem/
Я добавил некоторые детали в мой файл ~ / .ssh / config:
Хост heroku.com
Hostname heroku.com
Порт 22
IdentitiesOnly да
IdentityFile ~ / .ssh / id_heroku
TCPKeepAlive да
Brandon Пользователь
Мне пришлось использовать User в качестве адреса электронной почты для heroku.com. Примечание: это означает, что вам нужно создать ключ, я следовал этому, чтобы создать ключ, и когда он запрашивает имя ключа, обязательно укажите id_heroku http: / /help.github.com/win-set-up-git/
ключи героя: добавьте ~ / .ssh / id_heroku.pub
источник
Для меня было важно обновить переменную среды CYGWIN с помощью: " tty nodosfilewarning ". Даже не нужно chmod ключ.
источник
Не прямой ответ на основной вопрос, но на ваш вопрос о том, как работает папка cygwin ... Как правило, cygwin помещает все «ваши» файлы в эквивалент c: \ cygwin \ home \ username. Он обрабатывает эту папку для любых пользовательских настроек, а не для пользовательского каталога Windows.
источник
Если нет причины, по которой вы хотите сохранить эту пару закрытых / открытых ключей (id_rsa / id_rsa.pub) или не хотите биться головой о стену, я бы рекомендовал просто воссоздать их и обновить ваш открытый ключ на github.
Начните с создания резервной копии вашей директории ~ / .ssh.
Введите следующее и ответьте «y», хотите ли вы перезаписать существующие файлы.
Скопируйте содержимое открытого ключа в буфер обмена. (Ниже описано, как это сделать на Mac).
Зайдите в свой аккаунт на github и добавьте этот ключ.
Выйдите из вашего терминала и перезапустите новый.
Если вы получаете бессмысленные сообщения об ошибках, такие как «Введите свой пароль» для вашего открытого ключа, когда вы никогда его не вводите, рассмотрите эту методику «начать сначала». Как вы видите выше, это не сложно.
источник
Мне никогда не удавалось заставить Git работать полностью в Powershell. Но в оболочке git bash у меня не было проблем, связанных с разрешениями, и мне не нужно было устанавливать chmod и т. Д. После добавления ssh в Github я был запущен и работал.
источник
Тип на терминале:
И попробуй еще раз.
источник
Вы скопировали файл ключа с другого компьютера?
Я просто создал
id_rsa
файл на клиентском компьютере, а затем вставил нужный ключ. Нет проблем с разрешениями. Нечего устанавливать. Это просто сработало. Это также работает, если вы используете PuTTYgen для создания закрытого ключа.Возможно, какая-то скрытая групповая проблема, если вы копируете ее с другого компьютера.
Протестировано на двух машинах с Windows 8.1. Использование Sublime Text 3 для копирования и вставки закрытого ключа. Использование Git Bash (Git-1.9.4-preview20140611).
источник
После обновления установки Cygwin до версии около февраля 2015 года (
1.7.34(0.285/5/3) 2015-02-04 12:14 x86_64 Cygwin
) я неожиданно наткнулся наUNPROTECTED PRIVATE KEY FILE
предупреждение.Я исправил эту проблему после запуска следующей команды:
( другой ответ на другой вопрос дает больше контекста)
источник
Ответ @ koby не работает для меня, поэтому я делаю небольшое изменение.
Это хорошо работает для меня на Mac.
источник
У меня была такая же проблема в Windows 10, где я пытался использовать SSH в Vagrant box. Это похоже на ошибку в старой версии OpenSSH. Что сработало для меня:
(Обратите внимание на «.exe», если вы используете Powershell)
Вы можете увидеть что-то вроде:
Обратите внимание, что в приведенном выше примере последний OpenSSH занимает второе место в пути, поэтому он не будет выполняться.
Чтобы изменить порядок:
источник
Моя система немного запуталась с bash / cygwin / git / msysgit / возможно-больше ...
chmod
не имел никакого влияния на ключ илиconfig
файл.Тогда я решил подойти к нему из Windows, который работал.
Properties
.Security
вкладку.Advanced
около основания.Change
рядом сOwner
верхом.Check Names
, затемOK
.Permission entries:
, выделите каждого пользователя, который не является "My-Awesome-Username", и выберитеRemove
. Повторяйте это, пока "My-Awesome-Username" не останется единственным.Edit
ниже.Type:
вверху установлено значениеAllow
, а затем установите флажок рядом сFull control
.Хит
OK
,Apply
,OK
,OK
.Попробуйте еще раз ...
Кажется, иногда mock-bash не может контролировать владельца файла. Это особенно странно, так как оно генерируется из скрипта mock-bash. Пойди разберись.
источник
Ни один из предложенных здесь обходных путей (chmod / chgrp / setfacl / windows perms) не работал для меня с msys64 на корпоративной виртуальной машине Windows 7. В конце концов я обошел проблему с помощью агента ssh с ключом, предоставленным на stdin. Добавление этого к моему
.bash_profile
делает его по умолчанию для моего логина:Теперь я могу делать git push and pull с помощью ssh пультов.
источник