Использование проверки подлинности с ключом ssh

Подключение удаленного репозитория Github

Дальнейшее описание предполагает, что у вас уже создан аккаунт на github.com.

1. Создание SSH-ключа

1. Создайте директорию .ssh, в которой будет сохранен ключ:

mkdir .ssh

2. Сгенерируйте ключ командой ниже.

ssh-keygen -t rsa

3. При запросе Enter file in which to save the key (home/u/user/.ssh/id_rsa) укажите:

./.ssh/id_rsa

4. Дважды введите пароль, который будет использоваться при подключении по SSH-ключу. Вы также можете оставить этот запрос пустым (нажав Enter), тогда подключение будет производиться без пароля.

На этом создание ключа завершено.

2. Добавление ключа в аккаунт Github

1. Выполните команду ниже, чтобы вывести содержимое публичного ключа id_rsa.pub в консоли:

cat ./.ssh/id_rsa.pub

2. Скопируйте содержимое ключа.

3. Сохраните его в своем аккаунте Github в разделе Settings -> SSH and GPG keys -> New SSH key.

3. Проверка подключения к Github

1. Выполните команду:

ssh -i ./.ssh/id_rsa git@github.com

2. При запросе Are you sure you want to continue connecting (yes/no)? введите yes.

3. Введите пароль, если вы указывали его при создании ключа. 

Если подключение было выполнено успешно, вы увидите сообщение .

4. Подключение к удаленному репозиторию Github

1

Выполните команду ниже, чтобы запустить менеджер ключей SSH-agent (обратите внимание, что должны быть использованы именно обратные кавычки):

eval `ssh-agent`

2. Добавьте в него созданный ключ:

ssh-add ./.ssh/id_rsa

3. В своем аккаунте Github найдите корректную ссылку для подключения к нужном репозиторию. Она будет иметь примерно следующий вид:

git@github.com:имя_пользователя/имя_репозитория.git

4. Подключите репозиторий, указав полученную ссылку в команде, например:

git remote add origin git@github.com:timewebtest/test.git

5. Теперь вы можете отправить локальную ветку master в ваш репозиторий на Github командой:

git push -u origin master

Если действие было выполнено успешно, вы увидите сообщение Branch ‘master’ set up to track remote branch ‘master’ from ‘origin’.

Настраиваем сервер

Давайте рассмотрим настройку доступа по SSH на стороне сервера.
В этом примере мы будем использовать метод для аутентификации пользователей.
Мы подразумеваем, что вы используете стандартный дистрибутив Linux типа Ubuntu.

Примечание

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

Для начала создадим пользователя и каталог для этого пользователя:

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

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

Теперь вы можете создать пустой репозиторий для них, запустив с параметром , что инициализирует репозиторий без рабочего каталога:

После этого Джон, Джози или Джессика могут отправить первую версию их проекта в этот репозиторий, добавив его как удаленный и отправив соответствующую ветку.
Заметьте, что кто-то должен заходить на сервер и создавать голый репозиторий каждый раз, когда вы хотите добавить проект.
Пусть  — имя хоста сервера, на котором вы создали пользователя и репозиторий.
Если он находится в вашей внутренней сети и вы создали DNS запись для , указывающую на этот сервер, то можно использовать следующие команды как есть (считая что это существующий проект с файлами):

Теперь все остальные могут клонировать его и отправлять в него изменения:

Этим способом вы можете быстро получить Git-сервер с доступом на чтение/запись для небольшой группы разработчиков.

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

Вы можете легко ограничить пользователя только действиями, связанными с Git, с помощью ограниченной оболочки , поставляемой вместе с Git.
Если указать её в качестве командного интерпретатора для пользователя , то он не сможет получить доступ к обычной командной оболочке на вашем сервере.
Для её использования, укажите вместо bash или csh для пользователя .
Для этого вы должны сначала добавить в если её там ещё нет:

Теперь можно изменить оболочку для пользователя используя :

Теперь пользователь может использовать SSH соединение только для работы с репозиториями Git и не может зайти на машину.
Если вы попробуете войти в систему, то вход будет отклонён:

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

В результате файл будет выглядеть следующим образом:

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

prev | next

Начало

Используйте SSH вместо HTTPS

Чтобы настроить на локальной машине разные аккаунты, мы будем использовать не обычное HTTPS-соединение, а SSH-ключи. Такой подход имеет свои достоинства и недостатки. GitHub периодически меняет свое мнение о том, какой вариант лучше, но вот вам цитата из документации GitHub, поясняющая, почему в данном случае нужно использовать именно SSH-ключи.

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

Нам это идеально подходит. Мы ведь не хотим каждый раз заново проходить аутентификацию; напротив, мы хотим отправлять свои коммиты в репозитории так, будто мы вообще не переключались между аккаунтами. Но как это сделать?

Небольшое примечание. Если вы хотите подробнее узнать о разнице между HTTPS и SSH, она отлично описана в документации GitHub.

Разбираемся в структуре SSH на вашей локальной машине

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

Но где на вашей машине хранятся эти ключи?

Они хранятся в директории по адресу . Там и будет все настраиваться. Приступим!

Примечание редакции Techrocks. У нас есть еще одна статья о SSH-ключах. Возможно, вам будет интересно.

Особенности работы с gpg

Для начала работы, нам нужно создать нашу пару ключей через gpg. Есть очень подробная дока от Гитхаба на этот счет -> https://help.github.com/articles/generating-a-new-gpg-key/

Это очень краткая, но понятная дока. Однако есть нюанс. На одной из моих машин генерация ключа была настолько долгой, что я подумал о том, что система зависла. В результате оказалось, что настройки железа и ядра системы не дают той энтропии для генерации случайных чисел, чтобы ключ можно было сгенерировать быстро. Для ускорения на stack overflow предлагаются разные решения, вплоть до активного чтения диска через sudo file / и записью в /dev/null данных из /dev/urandom.

Имеем решение простое, нужно установить rng-tools и ключ после этого начинает генерится быстро. rng-tools — это демон для генерации случайных чисел, который для энтропии использует несколько источников. В результате повышается уникальность генерируемых значений и скорость.

Привожу две ссылки для тех, кто столкнется с этой проблемой:

1. Начало исследования тут https://serverfault.com/questions/471412/gpg-gen-key-hangs-at-gaining-enough-entropy-on-centos-6.
2. Продолжение тут https://serverfault.com/questions/214605/gpg-does-not-have-enough-entropy

Git-secret

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

Вот на этом скринкасте автор подробно показывает как работать с продуктом: https://asciinema.org/a/41811

Однако, после того как решил использовать git-secret на интеграционной машине вылезла очень неприятная проблема, давно кем-то описанная в этой ишью: https://github.com/sobolevn/git-secret/issues/136

Вкратце, на машине где идет разработка стоит gpg 2.2.4, а на интеграционной gpg 2.1. Файлы, зашифрованные через git-secret на одной машине могут быть расшифрованны на другой машине только если версии gpg на боксах совпадают.

Казалось бы, давайте обновим версию 2.1 до последней из ветки 2.2, но выясняется, что это не просто сделать, особенно если у вас на сервере не совсем свежая версия дистрибутива. Извратиться, конечно, можно. Вот тут даже есть пошаговая инструкция: https://gist.github.com/vt0r/a2f8c0bcb1400131ff51. Плохо то, что в ней слишком много фрикций. И представьте, если у вас распределенная команда из 10 человек с разным опытом и бэкграундом, с разными операционками на рабочих машинах… Это слишком сложный способ.

Вот тут ребята из git-secret явно намекают, что быстрого фикса не будет https://github.com/sobolevn/git-secret/issues/228. Можно попытаться поэкспортить ключи в разных форматах, можно использовать gpg нужной версии через Докер, можно дождаться, когда в git-crypt запилят фичу Stable public key storage: https://github.com/sobolevn/git-secret/blob/master/RFC/RFC001.md

Глобальный .gitignore

Git также позволяет вам создать глобальный файл , в котором вы можете определить правила игнорирования для каждого Git-репозитория вашей локальной системы.

Файл может называться по вашему усмотрению и храниться в любом месте. Наиболее распространенным местом хранения этого файла является домашний каталог. Вам придется вручную создать файл и настроить Git для его использования.

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

1. Создайте файл:

2. Добавьте этот файл в Git-конфигурацию:

3. Откройте файл в текстовом редакторе и добавьте в него свои правила.

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

Переносим удалённый репозиторий на ПК

Перейдите на сайт desktop.github.com и скачайте GitHub Desktop — это приложение, которое позволит синхронизировать удалённый репозиторий на GitHub и файлы на вашем компьютере без командной строки терминала:

• Скачиваем приложение под свою операционную систему.
• Открываем приложение и проходим авторизацию — нужно указать электронную почту и данные вашего GitHub-аккаунта.
• Приложение синхронизируется с удалённым репозиторием и предложит выполнить одно из следующих действий: создать новый репозиторий, добавить локальную папку с компьютера в GitHub Desktop или клонировать существующий репозиторий в папку компьютера.

Мы создали тестовый удалённый репозиторий, поэтому выберем третий вариант — клонировать существующий репозиторий в папку компьютера.

После установки GitHub Desktop запросит синхронизацию с GitHub-аккаунтом. Если аккаунта нет, приложение предложит его создать
Рабочее пространство в GitHub Desktop — мы можем клонировать репозиторий, создать новый или перенести нужные файлы с компьютера
Выбираем репозиторий, сохраняем его на рабочем столе и жмём кнопку Clone

После клонирования репозитория в рабочем пространстве появятся три вкладки: Current Repository, Current Branch и Fetch origin.

• Current Repository — раздел позволяет переключаться между несколькими репозиториями, отслеживать невнесённые изменения (вкладка Changes) и смотреть историю коммитов (вкладка History).
• Current Branch — раздел позволяет переключаться между несколькими ветками проекта.
• Fetch origin — раздел обновляет внесённые изменения и синхронизирует файлы локального и удалённого репозитория.

Обратите внимание на раздел Current Repository и вкладку Changes. В левом нижнем углу есть окно для добавления коммитов и комментариев — это означает, что вы можете записывать каждый шаг, не посещая сайт GitHub

Рабочее пространство для работы с клонированным репозиторием
История изменений нашего репозитория

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория

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

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

Клонируем репозиторий с той же машины в директорию :

git clone /home/username/project myrepo

Клонируем репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

-s

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

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

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой , надо создать коммит слияния с основной:

git merge username-project/master

Команда сразу забирает изменения и проводит слияние с активной веткой.

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

git pull

Забрать изменения и метки из определенного репозитория:

git pull username-project --tags

Как правило, используется сразу команда .

git push — вносим изменения в удаленный репозиторий

После проведения работы в экспериментальной ветке, слияния с основной, необходимо обновить удаленный репозиторий (удаленную ветку). Для этого используется команда git push.

Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удалить ветку experimental:

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test

Добавляем новые файлы на ПК и переносим их в удалённый репозиторий

Папка с файлами нашего репозитория хранится на рабочем столе. Чтобы продолжить работу, откроем проект в редакторе кода: можно выбрать любую программу, и GitHub Desktop предлагает воспользоваться Atom.

Выбор редактора кода — дело вкуса. Мы будем работать с репозиторием в Visual Studio Code — это бесплатный редактор от компании Microsoft.

Папка с нашим тестовым репозиторием в Visual Studio Code

Создадим HTML-файл, добавим базовую структуру и посмотрим на боковое меню — HTML-файл подсвечен зелёным цветом. Это означает, что в проекте появились изменения и они ещё не добавлены в репозиторий на GitHub.

Редактор кода подсвечивает зелёным цветом новые файлы

Переходим в GitHub Desktop — созданный HTML-файл появится во вкладке Changes. Для его сохранения пишем коммит и переходим во вкладку History для просмотра изменений. Если изменения сохранились, нажимаем на Push origin и отправляем изменения в удалённый репозиторий.

Создание пары ключей SSH

Для начала нужно сгенерировать пару ключей SSH. В системах Mac или Linux для этого достаточно просто ввести следующие команды в терминал (замените адрес электронной почты в коде своим реальным адресом):

Настоятельно рекомендуется установить пароль на файлы ключей, поскольку это обеспечивает дополнительный  уровень безопасности. В операционных системах Windows есть отдельные инструменты для генерации пары ключей, например, PuTTY Gen. Но эта программа запрещена в некоторых странах, а потому она идет с оговоркой о необходимости согласовать ее использование с местным законодательством. Уточнив этот момент, можно войти на VPS, создать пару ключей, и скачать id_rsa и id_rsa.pub.

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

9 ответов

Лучший ответ

• В вашем профиле GitHub есть кнопка . Он расположен в правом верхнем углу веб-страницы.
• Нажмите на нее, и вы увидите левое меню .
• Внутри этого меню найдите параметр и нажмите его.
• Вы увидите опцию для добавления нового ключа.

27

Evgeny Karkan
24 Июл 2016 в 22:19

1. сгенерируйте свой ключ

   SSH — серийник

2. Визуализируйте свои ключи

   ls ~ / .ssh

   id_rsa id_rsa.pub

3. Запустить агент

   eval

4. Запустить агент

   ssh-add ~ / .ssh / id_rsa

8

Waldeyr Mendes da Silva
22 Май 2018 в 16:06

Мне нужно было указать, какой хост будет использовать какой SSH-ключ. В папке SSH на локальном компьютере, обычно в разделе , создайте / отредактируйте файл с именем , используя предпочтительный редактор, например vim или gedit .

И добавьте следующее с вашими git Host , HostName и ssh IdentityFile (путь к файлу закрытого ключа ssh):

3

Waqleh
23 Июл 2018 в 17:06

Получил после того, как потратил много времени …

В принятом ответе Shravan40 все было нормально, но я, идиот, добавил на github.com новый репозиторий с добавлением нового README.md, и это вызвало ошибку

После множества попыток я добавил новый репозиторий без нового README.md, и все было в порядке, но я не знаю причины. До вчерашнего дня при новой попытке я наконец заметил это …

Итак, мое решение в дополнение к ответу Shravan40s:

Может это кому то поможет …

-1

Ulli H
29 Июл 2016 в 14:43

За свой короткий опыт использования git с Linux я обнаружил, что есть два простых ответа на эту ошибку.

Запустите эти команды в этом порядке

Это изменит конфигурацию вашего файла конфигурации для использования источника HTTPS вместо SSH.

Теперь попробуйте запустить команды push или pull.

ИЛИ

Перезагрузите виртуальную машину Linux (если вы ее используете) и / или хост-машину. Перезагрузка неоднократно решала проблему.

-1

Blusteel408
6 Мар 2020 в 19:44

У меня была такая же проблема с моим ssh-соединением. Я пробовал работать через ssh, но не нашел рабочего решения. Итак, в этом случае я изменил свой удаленный URL-адрес с SSH на HTTPS. Я использовал команду: . Вы можете увидеть, что ваш удаленный URL-адрес изменился, используя: .

Более подробную информацию можно найти здесь

Это изменит ваш удаленный URL-адрес на HTTPS, поэтому теперь вам нужно будет ввести свое имя пользователя и пароль GitHub, чтобы отправить свой проект в удаленное репо. Я знаю, что ssh проще, чем HTTPS, что означает, что вам не нужно вводить свое имя пользователя и пароль, но это может быть полезно, если вы не нашли решения для его исправления через ssh, и вы спешите, чтобы код в ваше репо.

5

shreeshr
9 Ноя 2019 в 17:52

1. Сгенерируйте ключ SSH с помощью .
2. Скопируйте вывод в буфер обмена
3. Вставьте скопированный выше вывод в форму по адресу https://github.com/settings/ssh/new

27

Shravan40
17 Май 2020 в 12:17

1. убедитесь, что вы правильно назвали файлы «открытый ключ» и «закрытый ключ»; в точности как «id_rsa» и «id_rsa.pub». Это то, что вы можете найти в папке users / .ssh.

2. добавить публичный ключ в GitHub

3. Перезагрузите терминал (поддерживается bash) и попробуйте снова клонировать

Если у вас есть доступ для записи в репо, вы должны быть готовы выполнить эти изменения.

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

Удачного кодирования!

Vikas Pandey
21 Сен 2017 в 17:13

Если кто-то из вас сталкивается с такой же проблемой на Bitbucket, то вот решение:

Проблема: —— Демо @ L90TQCLQ MINGW64 / u / works (мастер) $ git clone ssh: //git@bitbucket.internal.abc.com: 5449 / rem / jenkinspipeline.git Клонирование в jenkinspipeline … git@bitbucket.internal.abc.com: В доступе отказано (публичный ключ). фатальный: не удалось прочитать из удаленного репозитория .

Убедитесь, что у вас есть правильные права доступа и репозиторий существует.

Решение: Демо @ L90TQCLQ MINGW64 / u / works (мастер) $ cat

Перейти к: https: //bitbucket.internal. abc.com/plugins/servlet/ssh/projects/REM/repos/jenkinspipeline/keys 1) Добавить ключи Скопируйте / вставьте туда значение ключа id_rsa.pub:

Готово! Теперь вы можете клонировать репозиторий git

KDemo @ L90TQCLQ MINGW64 / u / works (master) $ git clone ssh: //git@bitbucket.internal.abc.com: 5449 / rem / jenkinspipeline.git Клонирование в ‘jenkinspipeline’ … удаленный: Перечисление объектов: 1146, сделанный. удаленный: Подсчет объектов: 100% (1146/1146), готово. remote: Сжатие объектов: 100% (987/987), готово. удаленный: Всего 1146 (дельта 465), повторно используется 0 (дельта 0) Принимающие объекты: 100% (1146/1146), 149,53 КБ | 172.00 КБ / с, готово. Разрешение дельт: 100% (465/465), выполнено.

nk07
12 Дек 2019 в 10:57

Как сменить работу с HTTPS на SSH

Если у вас есть локальный (на вашем рабочем компьютере) репозиторий полученный по https, очень просто сменить доступ на SSH.

Для этого убедитесь что доступ по HTTPS, для этого выведите список remote:

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

Зайдите в репозиторий и скопируйте SSH ссылку доступа, перейдите в локальный репозиторий и удалите текущий remote origin:

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

проверьте список удаленных репозиториев:

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

На этом вопросы с доступом к вашим репозиториям на гитхабе закрыт!

Чистого кода и красивых коммитов!

Конфигурация core.sshCommand:

Начиная с Git версии 2.10.0, вы можете настроить это для каждого репо или глобально, поэтому вам больше не нужно устанавливать переменную среды!

• 3 Мне пришлось экспортировать оболочка переменную в переменную среды, чтобы эта работа работала, т.е. , тогда
• 8 @Abdull В Bash выполнение присваивания в той же строке, что и команда, экспортирует переменную среды только для этой команды. Попытайся: .
• 3 вещи стали еще лучше: с Git 2.10 вы можете сохранить команду в своей конфигурации Git: stackoverflow.com/a/38474220/520162
• 2 @Noitidart является допустимым именем файла только в UNIX-подобных операционных системах, он не работает в Windows.
• 6 Для меня не работал, пока я не использовал , например, эта команда: .

Есть нет непосредственный путь сказать какой закрытый ключ использовать, потому что он зависит от для аутентификации репозитория. Однако есть еще несколько способов достичь поставленной цели:

Git-crypt

Рассмотрим первый тул из списка: git-crypt https://github.com/AGWA/git-crypt. Особенность, отличающая его от blackbox в том, что он шифрует и расшифровывает ваши сикреты на лету, прозрачно, без явного вызова команд и встраивается в git. Таким образом у вас появляется новая команда в гите: git crypt.

Процесс настройки простой (он весь описан в ридмишке проекта, там очень просто):

1. вы создаете файл .gitattributes и в нем прописываете список файлов сикретов либо явно, либо по маске
2. добавляете своего gpg юзера
3. дальше процесс происходит прозрачно, можно смело пушить конфиги в репо, они будут зашифрованы

Я пару раз ловил себя на мысли, что при пуше очкую, вдруг файл не включится в процесс шифрования, вдруг не сработала маска или криво описал все в .gitattributes. На этот счет я перед пушем запускаю команду git-crypt status -e которая показывает список файлов, которые будут зашифрованы. Вижу там свой файл, успокаиваюсь и пушаю.

Когда выгодней юзать git-crypt?

Когда в проекте всего два участника: вы и ваша CI (или сервер, где вы делаете git pull для деплоя), использовать его — одно удовольствие. Но в git-crypt есть две большие проблемы, которые мешают проекту быть использованным большой командой для серьезной работы:

1. Он не поддерживается мейнтейнером вот уже год, а форка-преемника пока не появилось.
2. Нет опции удаления пользователей из группы, которая шифрует и дешифрует сикреты. Вот тут: https://github.com/AGWA/git-crypt/issues/47 автор объясняет почему это сложно. Хотя мне кажется, что процедурно не сложно вообще. Как только ты убираешь из группы человека, то есть он выходит из проекта, надо менять все сикреты. Автор считает, что сикреты менять не надо, надо хранить историю… Автор живет в своем виртуальном мире.