credential helper selector что это

Хранилище учётных данных

Если для подключения к удалённым серверам вы используете протокол SSH, то вы можете использовать ключ вместо пароля, что позволит вам безопасно передавать данные без ввода логина и пароля. Однако, это невозможно при использовании HTTP-протоколов — каждое подключение требует пары логин, пароль. Всё ещё сложнее для систем с двухфакторной аутентификацией, когда выражение, которое вы используете в качестве пароля, генерируется случайно и его сложно воспроизвести.

К счастью, в Git есть система управления учётными данными, которая может помочь в этом. В Git «из коробки» есть несколько опций:

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

В режиме «cache» учётные данные сохраняются в памяти в течение определённого периода времени. Ни один из паролей никогда не сохраняется на диск и все они удаляются из кеша через 15 минут.

В режиме «store» учётные данные сохраняются на неограниченное время в открытом виде в файле на диске. Это значит что, до тех пор пока вы не измените пароль к Git-серверу, вам не потребуется больше вводить ваши учётные данные. Недостатком такого подхода является то, что ваш пароль хранится в открытом виде в файле в вашем домашнем каталоге.

На случай если вы используете Mac, в Git есть режим «osxkeychain», при использовании которого учётные данные хранятся в защищённом хранилище, привязанному к вашему системному аккаунту. В этом режиме учётные данные сохраняются на диск на неограниченное время, но они шифруются с использованием той же системы, с помощью которой сохраняются HTTPS-сертификаты и автозаполнения для Safari.

В случае если вы используете Windows, вы можете установить помощник, называемый «Git Credential Manager for Windows». Он похож на «osxkeychain», описанный выше, но для управления секретной информацией использует Windows Credential Store. Найти его можно по ссылке https://github.com/Microsoft/Git-Credential-Manager-for-Windows.

Вы можете выбрать один из этих методов, изменив настройки Git:

, который определяет где будет хранится файл с открытыми учётными данный (по умолчанию используется

Под капотом

Это команда, которая начинает взаимодействие.

После этого Git-credential ожидает данные из стандартного потока ввода. Мы передаём ему то, что знаем: протокол и имя сервера.

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

После этого Git-credential выполняет какую-то работу и выводит обнаруженную информацию.

Если учётные данные не найдены, Git спрашивает у пользователя логин/пароль, и выводит их обратно в задействованный поток вывода (в данном примере это одна и та же консоль).

get запрос логина и пароля.

store запрос на сохранение учётных данных в памяти помощника.

erase удаляет учётные данные для заданных параметров из памяти используемого помощника.

Ниже приведён пример, используемый ранее, но вместо git-credential напрямую вызывается git-credential-store:

Теперь мы извлечём эти учётные данные. Мы передаём часть уже известных нам параметров подключения ( https://mygithost ) и пустую строку.

git-credential-store возвращает логин и пароль, которые мы сохранили ранее.

Ниже приведено содержимое файла

Это просто набор строк, каждая из которых содержит URL, включающий в себя учётные данные. Помощники osxkeychain и wincred используют форматы, лежащие в основе их хранилищ, а cache использует его собственный формат хранения во внутренней памяти (который другие процессы прочитать не могут).

Собственное хранилище учётных данных

Поскольку git-credential-store и подобные ей утилиты являются отдельными от Git программами, не сложно сделать так, чтобы любая программа могла быть помощником авторизации Git. Помощники, предоставляемые Git, покрывают наиболее распространённые варианты использования, но не все. Для примера допустим, что ваша команда имеет некоторые учётные данные, совместно используемые всей командой, например, для развёртывания. Эти данные хранятся в общедоступном каталоге, но вы не хотите копировать их в ваше собственное хранилище учётных данных, так как они часто изменяются. Ни один из существующих помощников не покрывает этот случай; давайте посмотрим, что будет стоить написать свой собственный. Есть несколько ключевых особенностей, которым должна удовлетворять эта программа:

Мы должны уделить внимание только одной операции get ; store и erase являются операциями записи, поэтому мы не будем ничего делать при их получении.

Расположение это файла более-менее стандартное, но, на всякий случай, мы должны позволять пользователям передавать свой собственный путь.

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

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

Эта программа отвечает только если операцией является get и файл хранилища существует.

Этот цикл читает содержимое файла хранилища, выполняя поиск соответствия. Если протокол и сервер из known соответствуют текущей строке, программа выводит результат и завершает работу.

Так как его имя начинается с «git-», мы можем использовать простой синтаксис для настройки:

Как вы видите, расширять эту систему довольно просто и это позволяет решить некоторые общие проблемы, которые могут возникнуть у вас и вашей команды.

Источник

Что нам стоит Git настроить!

Дарова, хабр! (ничего оригинальнее не придумал)

Сомневаюсь что эта заметка тянет на полноценный пост, но я все же оставлю ее здесь. О чем же пойдет речь?

Читайте также: drive lock что это

Все мы слышали о Git. Все мы знаем что он — хорош. Но лишь немногие пытаются что-то с ним делать, как-то его протвикерить. Сразу говорю, тут не будет ничего паранормального, только немного работы с файлом .gitconfig. Да-да, именно с тем файлом, который так трепетно пылится у вас в домашней директории.

Так, мне уже немного надоело писать этот, по сути, бессмысленный вступительный текст, так что давайте уже начнем что-то делать.

Не знаю как на других системах, но в Linux он лежит в

. Если его там нету — смело создавайте!

Подсветка вывода

Себя записываем

Зачем это нужно? Если вы запустите git log для какого-то репозитория, вы увидите что для каждого коммита, автор характеризируется через Name и Email. Чтобы нас правильно нашли, настало время задать все это правильно. Внимание! Менять эту информацию во время разработки крайне нежелательно. Она может поломать историю (множественные автора)! Желательно единажды выбрать какое-то имя и конкретный Email.

Шаблон коммитов

Не знаю как другие хабровчане работают, но в основном мои коммиты идут в KDE Edu проекты. Там четко диктуют правила формы и вида коммита, так как он парсится разными ботами и т.д. Чтобы не дай Бог ошибиться или что-то неправильно сделать существуют шаблоны. Такой шаблон очень просто сделать (а можно и взять где-то). Чтобы он отображался во время git commit нужно добавить такое:

/.commit-template конечно же может быть любым файлом в вашей файловой системе.

Credential Helper

Бывает такое что нужно выполнить несколько операций с удаленным репозиторием за раз. Каждый раз вводить имя и пароль, имя и пароль, имя и… Напрягает, нет? Меня напрягает. Начиная с версии 1.7.10 Git поддерживает Credential Helper.

Ставим нужное время (у меня это 3600 — один час) и радуемся!

Алиасы для частых команд

Я очень часто пользуюсь командами checkout и branch, например. Писать по три-четыре раза одно и тоже — надоедает. Давайте заменим их на более лаконичный вариант: cd и dir, например.

А теперь посмотрим что мы сделали:

Без модификаций	С модификациями

Префиксы для remote

Есть один трюк, который нередко используется разработчиками. Это префиксы для remote. Они позволяют сократить длину адреса к удаленному репозиторию. Можно задать такие для read-only и push. Зачем? Это логично для open-source проектов. Для уменшения нагрузки на сервер и скорости, лучше pull’ить из anongit (read-only) без использования SSH. Что стоит у меня для KDE?

Давайте разбираться. Тут мы настроили два URL для pull и push. Задали префикс kde. Что это нам дает? Посмотрим на примере (в статье не указан префикс gh — для GitHub):

Без модификаций	С модификациями

Стало лучше, не правда ли?

Заключение

В статье были опущены мои всякие «экзотические» алиасы и доп. префиксы для разных сервисов. Смело могу сказать, что после того как потвикерил Git — работать стало приятнее. Все знакомые, которые опробовали это — согласились со мной.

P.S. Если я что-то делаю неправильно или я уже совсем убогий, пожалуйста, отпишите ко мне в ЛС и сообщите/посоветуйте (если вам не сложно, конечно).

UPD: Больше интересного и свежего можно найти тут.

Источник

Как избежать указания имени пользователя и пароля при каждом нажатии git?

Я git push моя работа в удаленном репозитории Git.

18 ответов:

1. Сгенерировать ключ SSH

Linux / Mac

откройте терминал для создания ssh ключей:

Для Windows

(работает только в том случае, если программа фиксации способна использовать сертификаты/закрытые и открытые ключи ssh)

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

2. Свяжите ключ SSH с удаленным репозиторием

этот шаг зависит от настройки пульта дистанционного управления.

если это репозиторий GitHub и у вас есть права администратора, перейдите к настройки и нажмите кнопку «добавить ключ SSH». Скопируйте содержимое вашего

/.ssh/id_rsa.pub в поле «Ключ».

если ваш удаленный репозиторий управляется вами, вы можете использовать эту команду, например:

3. Установите удаленный URL-адрес в форму, которая поддерживает SSH 1

если вы выполнили описанные выше действия и все еще получаете запрос пароля, убедитесь, что Ваш URL-адрес РЕПО находится в форме

чтобы увидеть URL вашего РЕПО, выполните:

вы можете изменить URL-адрес:

_{[1] в этом разделе содержится ответ от Эрик Р}

постоянная аутентификация с помощью репозиториев Git,

выполните следующую команду, чтобы включить кэширование учетных данных.

использовать также следует указать срок действия кэширования истекает,

после включения кэширования учетных данных, он будет кэшироваться для 7200 секунд (2 часа).

Примечание: набор вспомогательных хранить незашифрованный пароль на локальный диск.

если вы уже настроили ключи SSH и все еще получаете запрос пароля, убедитесь, что Ваш URL-адрес РЕПО находится в форме

чтобы увидеть URL вашего РЕПО, выполните:

вы можете изменить URL с помощью git remote set-url вот так:

Сохранение На Неопределенный Срок

можно использовать git-credential-store через

использование этого помощника будет хранить ваши пароли в незашифрованном виде на диске, защищенном только разрешениями файловой системы. Если это неприемлемый компромисс безопасности, попробуйте git-credential-cache или найдите помощника, который интегрируется с безопасным хранилищем, предоставляемым вашей операционной системой система.

с таймаутом

использовать git-credential-cache который по умолчанию хранит пароль в течение 15 минут.

Безопасное Сохранение На Неопределенный Срок (OS X и Windows)

я использовал https ссылку ( https://github.com/org/repo.git ) вместо ссылки ssh;

переключение решило проблему для меня!

подключите Git-клиент к хранилищу учетных данных ОС. Например, в Windows вы привязываете помощник учетных данных к wincred:

я использовал ответ, который предложил Павел, и это сработало для меня. Моя разница заключалась в том, чтобы сделать это, пока я добавлял пульт так: git remote add (alias) https://(name:password)@github.com/(the remote address).git

в операционной системе Windows используйте это вместо этого, это работает для меня:

просто хотел указать что-то о решении, сказанном выше несколько раз:

вы можете использовать любую команду, которая требует после этого пароль. Тебе не нужно давить. (вы также можете вытащить, например) после этого вам не нужно будет снова вводить свое имя пользователя / пароль.

все это возникает из-за того, что git не предоставляет опцию в командах clone/pull/push/fetch для отправки учетных данных через канал. Хотя это дает верительные грамоты.помощник, он хранит в файловой системе или создает демон и т. д. Часто учетные данные GIT являются системными, и ответственность за их безопасность лежит на приложении, вызывающем команды git. Очень небезопасно.

GIT CLONE

для клонирования, с помощью «ЖКТ URL-адрес клонировать» после изменения URL-адреса из формата, в HTTP://<мой_логин>@/ в http:/ / : @ /

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

очистка

теперь, это пошло бы и

Если ваше приложение использует Java для выполнения этих команд, используйте ProcessBuilder вместо Runtime. Если необходимо использовать Runtime, используйте getRunTime ().exec, который принимает массив строк в качестве аргументов с /bin / bash и-c в качестве аргументов, а не тот, который принимает одну строку в качестве аргумента.

GIT FETCH / PULL / PUSH

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

предупреждение: это по своей сути небезопасно, потому что:

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

вот почему использование ключа SSH является принятым ответом.

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

вы должны настроить SSH закрытый ключ, вы можете просмотреть это страница, Как сделать установку на Mac, Если вы находитесь на linux руководство должно быть почти то же самое, на Windows вам понадобится инструмент, как MSYS.

создайте SSH-ключи в своей системе linux, используя следующую команду

Он будет запрашивать пароль и имя файла (по умолчанию

после создания файлов добавьте открытый ключ id_rsa.паб в раздел ssh учетной записи github.

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

Теперь добавить git@github.com:user_name/repo_name.git удаленного URL-адреса на локальный репозиторий Git, используя следующую команду.

похоже, что, по крайней мере, при использовании TortoiseGIT в Windows, можно создать ключи SSH и передать их на сервер GIT, используя просто:

вы должны настроить удаленный URL ssh, как описано выше.

запуск команды ниже решил проблему для меня.

пожалуйста, обратитесь к приведенной ниже документации github:

Источник

Как отключить помощник учетных данных git для одного репозитория?

Если у меня есть вспомогательный набор учетных данных в моем

Я использую Git версию 1.7.12.

ОТВЕТЫ

Ответ 1

С git 2.9 (июнь 2016 года) это ( helper = ) будет работать!

Конфигурационная переменная credential.helper является кумулятивной, и нет хорошего способа переопределить ее из командной строки.
В качестве специального случая , дающий пустую строку, поскольку ее значение теперь служит сигналом для очистки значений, указанных в разных файлах.

credential : пусть пустые спецификации учетных данных reset список помощников

Так как ключ credential.helper является многозначным списком конфигураций, нет способа «отменить» помощника после его установки. Поэтому, если ваша система /etc/gitconfig устанавливает один, вы никогда не сможете ее запустить, но только добавьте свои собственные помощники сверху.

Так как пустое значение для credential.helper бессмысленно (он просто попытается запустить » git-credential- » ), мы можем предположить, что его никто не использует. Пусть он определяет reset список помощников, позволяя вам переопределять экземпляры с более низким приоритетом, которые раньше.

Ответ 2

То, что я пробовал, и сработало хорошо:

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

Ответ 3

Таким образом, в основном ваши варианты выглядят следующим образом:

либо не использовать credential.helper в

или реализовать собственный помощник, который ничего не делает для набора сконфигурированных репозиториев и делегатов для git credential-store для остальных.

Ответ 4

В дополнение к git config credential.helper= ‘, который я упоминал выше с Git 2.9, вы теперь (Git 2.13.x/ Git 2.14, Q3 2017) может отключить помощник учетных данных только для одной команды (а не только для любой команды в заданном репо)

Читайте также: crm getcourse что это

Заметили при попытке установить credential.helper во время клонирования, чтобы использовать конкретный помощник, не наследуя от

намереваясь создать конфигурацию:

Обратите внимание, что документация теперь понятна с помощью commit 515360f:

credential doc: сделать несколько помощников более заметными

Git система конфигурации работает, читая несколько файлов конфигурации по порядку, от общего к конкретному:

Для объектов с однозначной конфигурацией выигрывает последнее значение.
Для многозначных элементов конфигурации значения накапливаются в этом порядке.

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

Иногда люди хотят переопределить унаследованную настройку.
Для параметра credential.helper это делается установкой элемента конфигурации пустым, прежде чем присвоить ему новое значение.

Ответ 5

Я просто столкнулся с этой проблемой, так как первый настроенный мной credential.helper всегда выполнялся, когда я хотел протестировать новый. Это на macOS с использованием git, поставляемого с инструментами Apple dev.

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

Наконец нашел настройки в двух местах:

Источник

I always get a popup credential helper selector asking me to choose a credential helper

And it comes back even if I set «always choose this form now on» to true

2 answers

1 accepted

Same issue. Just installed the latest version of SourceTree (3.3.9) on a fresh build of Windows 10 v2004