Переходим с HTTPS на SSH доступ в GitHub
Table of Contents
C 13 августа 2021 года Github блокирует доступ по HTTPS протоколу к репозиториям, то есть теперь вы не сможете, получить или отправить изменений в удаленный репозиторий без SSH ключа.
В этом гайде покажу как создать ключ, загрузить на сервер и перенастроить локальный репозиторий на SSH доступ. В качестве примера используется Windows 10 и GitBash.
Что необходимо
Создание пары ключей SSH
Открывайте GitBash или терминал, вводите:
После заходите в папку.
В итоге для запуска генерации ключа, выполните:
Вам будут заданы несколько вопросов:
Подтвердить кодовую фразу или ее отсутсвие, тоже нажав Enter.
В результате вам покажут рисунок вашего ключа:
Вывод должен быть таким:
Активация ключа
Для того чтобы ключ использовался системой, необходимо добавить ключ в ssh-agent.
результат, номер процесса может отличаться:
Добавьте ранее созданный ключ:
При успехе получите ответ:
Ключи SSH готовы к использованию!
Добавление публичного ключа в профиль на GitHub
ℹ Кратко про ключи. С помощью публичного ключа, каждый может зашифровать информацию, расшифровать может только владелец приватного ключа, поэтому приватный ключ нельзя передавать, отправлять или хранить в открытом виде. Желательно пару ключей дополнительно скопировать на отдельный носитель, на случай потери ключа на компьютере.
В GitHub для работы с репозиториями скопируйте публичный ключ, одним из способов:
это скопирует публичный ключ в буфер обмена.
Нажимайте не кнопку New SSH Key
В поле Key вставьте скопированный ключ:
В поле Title можете вставить название ключа, пригодится если у вас будет в профиле более одного ключа. Поможет их различать.
Теперь можно использовать SSH доступ к вашим репозиторияем!
Получение репозитория по SSH
Откройте репозиторий и скопируйте ссылку для SSH доступа:
И как обычно используйте команду git clone:
Как сменить работу с HTTPS на SSH
Если у вас есть локальный (на вашем рабочем компьютере) репозиторий полученный по https, очень просто сменить доступ на SSH.
Для этого убедитесь что доступ по HTTPS, для этого выведите список remote:
ссылки начинаются c https, а значит вы не можете ни загрузить ни получить обновления удаленного репозитория.
Зайдите в репозиторий и скопируйте SSH ссылку доступа, перейдите в локальный репозиторий и удалите текущий remote origin:
и добавьте новый, последняя строка в команде это ссылка доступа SSH:
проверьте список удаленных репозиториев:
и если у вас формат без https в начале ссылки, то все выполнено верно, можно работать с репозиторием и проверить командой git fetch
На этом вопросы с доступом к вашим репозиториям на гитхабе закрыт!
Генерация SSH-ключа для работы с GitHub
Во-первых, нам нужно проверить, установлен ли у вас уже SSH-ключ. Введите это в терминал:
Если в консоли появляется сообщение с текстом «Нет такого файла или каталога», значит, у вас еще нет SSH-ключа, и вам нужно будет его создать. Если в выводе консоли не появилось никакого сообщения, значит, у вас уже есть ключ.
Добавление созданных SSH-ключей в SSH-агент
Убедимся что SSH-агент включён:
Запускаем агента, он работает в фоновном режиме. В консоли должен появиться id запущенного процесса.
Пример (у вас он будет свой)
Добавим SSH-ключ в SSH-агент.
Если вы хотите использовать уже существующие ключи, вместо только что сгенерированных, тогда нужно заменить id_rsa при вводе команды в консоли именем существующего файла, содержащий приватный ключ.
В случаем использования только что созданных ключей просто вводим в консоль Git команду:
Результат который получите (у вас будет свой)
А теперь вам нужно сообщить GitHub, какой у вас SSH-ключ, чтобы вы могли отправлять свой код, не вводя каждый раз пароль.
Сначала вы перейдете туда, где GitHub получает наш SSH-ключ. Войдите в GitHub и щелкните изображение своего профиля в правом верхнем углу. Затем нажмите на Settings в раскрывающемся меню.
Выделите и скопируйте результат, который начинается с ssh-rsa и заканчивается вашим адресом электронной почты.
Если у вас будет ошибка, то этот ключ можно найти на вашем локальном компьютере.
Откройте в любом текстовом редакторе, скопируйте ключ и добавьте на сайте.
Автор курса: Олег Данилюк (по всем вопросам)
Как пользоваться GitLab
В этой статье мы поговорим о том, как пользоваться GitLab для разработки своих проектов. Как создавать репозитории и взаимодействовать с ними. Если вам нужна информация по Git, то лучше смотрите статью как пользоваться git.
Как пользоваться GitLab
1. Создание аккаунта
Зарегистрироваться на GitLab очень просто. Откройте главную страницу GitLab найдите в правой части экрана форму входа и перейдите на вкладку Register. Здесь вам нужно ввести ваше имя, логин, адрес электронной почты, согласится с условиями использования и нажать кнопку Register:
После этого вам на почту придет сообщение со ссылкой для подтверждения аккаунта, перейдите по ней:
Теперь ваш аккаунт подтвержден и вы можете в нём авторизоваться:
После ввода логина и пароля вы попадете на главную страницу профиля. Сейчас здесь страница приветствия, но позже тут будет список ваших репозиториев:
2. Создание репозитория
Чтобы добавить проект GitLab кликните по значку + по центру верхней панели и выберите New Project:
Здесь вам нужно ввести имя репозитория, его описание, а также выбрать уровень доступа:
Ещё вы можете установить галочку напротив Инициализировать репозиторий файлом README, но если вы хотите залить сюда файлы из уже существующего репозитория, делать этого не следует:
После нажатия на кнопку Create repo вы попадаете на страницу репозитория. Здесь GitLab уже предлагает первоначальный набор действий, чтобы проиниализировать ваш репозиторий. Например, вы можете создать здесь файлы или загрузить сюда файлы из вашего компьютера.
4. Загрузка файлов проекта
Давайте создадим новый локальный репозиторий на компьютере и загрузим его содержимое на GitLab. Для этого создайте папку репозитория, например, test-repo и инициализируйте в ней новый репозиторий командой git:
mkdir test-repo && cd test-repo
Затем давайте создадим файл test.txt:
This is test losst repo
И зафиксируем изменения:
Дальше нам нужно добавить наш удаленный репозиторий с GitLab к нашему локальному. Для этого выполните:
git remote add origin https://gitlab.com/losst/test-repo.git
Затем отправляем изменения в удаленный репозиторий:
git push origin master
Для отправки данных нужно ввести ваш логин и пароль на GitLab. Теперь, если вы обновите страницу репозитория на GitLab, то увидите там наш файл:
Важно отметить, что если удаленный репозиторий не пуст, то у вас не получиться так сделать. Вам нужно будет сначала скачать удаленный репозиторий, слить локальные изменения с ним, а потом уже отправить всё назад.
5. SSH ключи
Во время загрузки данных репозитория на GitLab нам нужно было ввести логин и пароль на сервере. Чтобы этого избежать можно использовать SSH ключи для авторизации. Сначала вам нужно создать такой ключ. Для этого откройте терминал и выполните:
Далее возвращайтесь к интерфейсу GitLab кликните по иконке профиля и выберите Settings:
Здесь на левой панели найдите пункт SSH Keys. В этом окне найдите поле Key и вставьте туда скопированный ключ. Далее сохраните изменения. Теперь ваш ключ добавлен:
Далее вернитесь в ваш репозиторий, найдите в правом верхнем углу кнопку Clone и кликните по ней. Нас интересует адрес Clone with SSH:
Возвращаемся к нашему локальному репозиторию, удаляем адрес https и добавляем ssh:
git remote remove origin
git remote add origin git@gitlab.com:losst/test-repo.git
Настройка ssh GitLab завершена. Теперь все действия будут выполняться по SSH и у вас не будет необходимости вводить логин и пароль.
6. Ветки репозитория
Создать новую ветку можно кликнув по значку плюс и выбрав New branch. Но это не обязательно, так как если вы создадите ветку в git и зальете изменения в репозиторий, то ветка появится там автоматически.
6. Слияние веток
Поскольку у нас есть ветки и в них разрабатывается функциональность может возникнуть необходимость перенести её из одной ветки в другую. Для этого используются запросы слияния (Merge request gitlab). Давайте добавим ветку new-feature, а в ней создадим файл new-feature с текстом:
New feature with change
Теперь, когда мы перейдем в новую ветку через интерфейс GitLab появится кнопка Create merge request. Нажмите на неё:
Здесь нужно написать описание Merge Request, который вы создаете, выбрать ветку источник и ветку цель. Также можно выбрать пользователя, которому будет оправлено уведомление о созданном запросе:
Далее запрос на слияние нужно одобрить. Вы можете посмотреть изменения нажав кнопку Open IDE или через терминал:
Далее просто нажмите кнопку Merge, если хотите слить ветки. Файлы ветки источника заменят файлы в ветке преемника, поэтому будьте осторожны, чтобы не потерять важные данные.
8. Добавление пользователей
Затем нажмите кнопку Add to project.
9. Удаление проекта
После нажатия на кнопку вам нужно будет ввести имя проекта, после чего он будет удален:
Выводы
В этой статье мы кратко разобрали как пользоваться GitLab для разработки программного обеспечения. Это далеко не все возможности GitLab, которые заслуживают внимания, там ещё есть релизы, сообщения об ошибках, инструменты автоматизации и тестирования, удобный редактор кода и многое другое. В общем это полноценная альтернатива для GitHub если тот сервис больше вам не нравится. А что вы предпочитаете, GitHub или GitLab? Напишите в комментариях!
Использование проверки подлинности с ключом SSH
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2015
URL-адреса SSH изменились, но старые URL-адреса SSH продолжат работать. Если вы уже настроили SSH, необходимо обновить удаленные URL-адреса в новом формате:
начиная с Visual Studio 2017 можно использовать SSH для подключения к Azure DevOps репозиториев Git.
Как работает проверка подлинности SSH-ключа
Проверка подлинности с помощью открытого ключа SSH работает с асимметричной парой созданных ключей шифрования. открытый ключ предоставляется Azure DevOps и используется для проверки первоначального ssh-подключения. Закрытый ключ обеспечивает безопасность и безопасность в системе.
Настройка проверки подлинности ключей SSH
Следующие шаги охватывают настройку проверки подлинности ключей SSH на следующих платформах:
Настройте SSH с помощью командной строки. bash является общей оболочкой в Linux и macOS, а git для Windows установки добавляет ярлык для git Bash в меню. Другие среды оболочки будут работать, но не будут рассмотрены в этой статье.
Шаг 1. Создание ключей SSH
Если вы уже создали ключи SSH в системе, пропустите этот шаг и перейдите к разделу Настройка ключей SSH.
Команды здесь позволяют создавать новые ключи SSH по умолчанию, перезаписывая существующие ключи по умолчанию. Прежде чем продолжить, проверьте
/.ssh папку (например,/Хоме/Жамал/.СШ или к:\усерс\жамал\.СШ) и найдите следующие файлы:
Если эти файлы существуют, вы уже создали ключи SSH. Вы можете перезаписать ключи с помощью следующих команд или пропустить этот шаг и перейти к разделу Настройка ключей SSH для повторного использования этих ключей.
Создайте ключи SSH с помощью ssh-keygen команды из bash командной строки. Эта команда создаст 3072-разрядный ключ RSA для использования с SSH. При появлении запроса можно предоставить парольную фразу для закрытого ключа — Эта парольная фраза обеспечивает еще один уровень безопасности для закрытого ключа. Если вы выдаете парольную фразу, обязательно Настройте агент SSH для кэширования парольной фразы, чтобы не вводить его каждый раз при подключении.
Эта команда создает два ключа, необходимых для проверки подлинности SSH: ваш закрытый ключ ( id_rsa ) и открытый ключ ( id_rsa. pub ). Важно никогда не предоставлять общий доступ к содержимому закрытого ключа. Если закрытый ключ скомпрометирован, злоумышленники могут использовать его, чтобы заставить серверы подумать о том, что подключение поступает от вас.
шаг 2. добавление открытого ключа в Azure DevOps Services/тфс
Свяжите открытый ключ, созданный на предыдущем шаге, с ИДЕНТИФИКАТОРом пользователя.
Выберите + новый ключ.
Шаг 2. Добавление открытого ключа в Azure DevOps
Свяжите открытый ключ, созданный на предыдущем шаге, с ИДЕНТИФИКАТОРом пользователя.
Выберите + новый ключ.
Шаг 3. Клонирование репозитория Git с помощью SSH
Сведения о подключении по протоколу SSH из существующего клонированного репозитория см. в разделе обновление удаленных служб до SSH.
Project url-адреса были изменены в выпуске Azure DevOps Services и теперь имеют формат dev.azure.com/
Выполните git clone в командной строке.
SSH отображает этот отпечаток при подключении к неизвестному узлу и защищает вас от атак типа «злоумышленник в середине». Приняв отпечаток узла, SSH не выводит запрос повторно, пока отпечаток не изменится.
Вопросы и устранение неполадок
Вопрос. После выполнения git clone я получаю следующую ошибку. Что следует делать?
Ответ . Вручную запишите ключ SSH, выполнив команду:
Вопрос. как с помощью Git запоминать парольную фразу для моего ключа на Windows?
Ответ . выполните следующую команду, входящую в Git, чтобы Windows запустить процесс в PowerShell или в Windows командной строке. ssh-agent кэширует вашу парольную фразу, чтобы не указывать ее при каждом подключении к репозиторию.
Если вы используете оболочку Bash (включая Git bash), запустите ssh-agent с:
Вопрос. я использую в качестве моего клиента SSH ввод и создал ключи с помощью PuTTYgen. Можно ли использовать эти ключи с Azure DevOps Services?
Ответ. Да. Загрузите закрытый ключ с помощью PuTTYgen, перейдите в меню преобразования и выберите Экспорт ключа OpenSSH. Сохраните файл закрытого ключа и выполните действия по настройке ключей, не относящихся к по умолчанию. Скопируйте открытый ключ непосредственно из окна PuTTYgen и вставьте в поле Data ( Ключевые данные ) в параметры безопасности.
Вопрос. Как убедиться, что открытый ключ, который я отправил, имеет тот же ключ, что и локальный?
Ответ . Отпечаток открытого ключа, который отображается в профиле, можно проверить с помощью следующей команды, выполняемой для открытого ключа в bash командной строке. Если значения по умолчанию не используются, необходимо будет изменить путь и имя файла открытого ключа.
Затем можно сравнить сигнатуру MD5 с той, которая есть в вашем профиле. Эта проверка полезна при возникновении проблем с подключением или при неправильном вводе открытого ключа в поле данных ключа при добавлении ключа в Azure DevOps Services.
Вопрос. как начать использовать SSH в репозитории, где сейчас используется протокол HTTPS?
Ответ . Вам потребуется обновить Удаленный в Git, чтобы изменить URL-адрес HTTPS на SSH. Получив URL-адрес клона SSH, выполните следующую команду:
вопрос. я использую Git LFS с Azure DevOps Services и получаю сообщения об ошибках при получении файлов, отслеживаниющих с помощью Git LFS.
ответ . Azure DevOps Services сейчас не поддерживает LFS через SSH. Используйте HTTPS для подключения к репозиториев с отслеживанием файлов LFS Git.
Вопрос. как использовать расположение ключа не по умолчанию, т. е. not/.СШ/id_rsa и
Ответ . Чтобы использовать ключи, созданные в, в другом месте, отличном от используемого по умолчанию, выполните следующие две задачи:
в Windows перед запуском необходимо ssh-add выполнить следующую команду из команды, включенной в Git, для Windows:
Эта команда выполняется как в PowerShell, так и в командной строке. При использовании git Bash необходимо использовать следующие команды:
его можно найти ssh-add как часть Git для Windowsного распространения, а также запускать в любой среде оболочки на Windows.
Вопрос. у меня несколько ключей SSH. Разделы справки использовать разные ключи SSH для разных серверов SSH или репозиториев?
Ответ . Как правило, если вы настроили несколько ключей для клиента SSH и подключились к серверу SSH, клиент может попытаться использовать ключи по одному, пока сервер не примет его.
однако это не работает с Azure DevOps по техническим причинам, связанным с протоколом ssh, и о том, как структурированы url-адреса SSH Git. Azure DevOps будет отменять первый ключ, предоставляемый клиентом во время проверки подлинности. Если этот ключ недопустим для запрошенного репозитория, запрос завершится со следующей ошибкой:
для Azure DevOps необходимо настроить SSH для явного использования определенного файла ключа. Один из способов сделать это для изменения
/.ssh/config файла (например, /home/jamal/.ssh или C:\Users\jamal\.ssh ) следующим образом:
Вопрос. Разделы справки исправить ошибки с упоминанием «не найден соответствующий метод обмена ключами»?
Ответ . Git для Windows 2.25.1 поставляется с новой версией OpenSSH, которая по умолчанию удалила некоторые протоколы обмена ключами. в частности, определено diffie-hellman-group14-sha1 как проблематичное для некоторых Azure DevOps Server и клиентов TFS. Эту проблему можно обойти, добавив следующую команду в конфигурацию SSH (
Вопрос. какие уведомления могут получать сведения о ключах SSH?
Ответ . при регистрации нового ключа ssh с Azure DevOps Services вы получите уведомление по электронной почте о том, что в учетную запись добавлен новый ключ ssh.
Вопрос. что делать, если я полагаю, что кто-то, помимо меня, добавляет ключи SSH в мою учетную запись?
Ответ . Если вы получили уведомление о регистрации SSH-ключа и вы не перегрузили его в службу вручную, возможно, ваши учетные данные были скомпрометированы.
Следующий шаг — выяснить, не был ли ваш пароль скомпрометирован. Изменение пароля всегда является хорошим первым шагом для защиты от этого вектора атак. если вы являетесь Azure Active Directory пользователем, обратитесь к администратору, чтобы проверить, использовалась ли ваша учетная запись из неизвестного источника или расположения.
Ответ . некоторые дистрибутивы linux, например Fedora Linux, имеют политики шифрования, требующие более строгих алгоритмов подписи SSH, чем поддерживает Azure DevOps (по состоянию на январь 2021). Есть запрос на открытие функции для добавления этой поддержки.
Можно обойти эту ошибку, добавив следующий код в конфигурацию SSH (
Using SSH keys with GitLab CI/CD
GitLab currently doesn’t have built-in support for managing SSH keys in a build environment (where the GitLab Runner runs).
If anything of the above rings a bell, then you most likely need an SSH key.
How it works
/.ssh/authorized_keys ) or add it as a deploy key if you are accessing a private GitLab repository.
SSH keys when using the Docker executor
When your CI/CD jobs run inside Docker containers (meaning the environment is contained) and you want to deploy your code in a private server, you need a way to access it. In this case, you can use an SSH key pair.
You first must create an SSH key pair. For more information, follow the instructions to generate an SSH key. Do not add a passphrase to the SSH key, or the before_script will prompt for it.
Create a new CI/CD variable. As Key enter the name SSH_PRIVATE_KEY and in the Value field paste the content of your private key that you created earlier.
The before_script can be set globally or per-job.
Make sure the private server’s SSH host keys are verified.
As a final step, add the public key from the one you created in the first step to the services that you want to have an access to from within the build environment. If you are accessing a private GitLab repository you must add it as a deploy key.
That’s it! You can now have access to private servers or repositories in your build environment.
SSH keys when using the Shell executor
If you are using the Shell executor and not Docker, it is easier to set up an SSH key.
You can generate the SSH key from the machine that GitLab Runner is installed on, and use that key for all projects that are run on this machine.
First, log in to the server that runs your jobs.
Then, from the terminal, log in as the gitlab-runner user:
Generate the SSH key pair as described in the instructions to generate an SSH key. Do not add a passphrase to the SSH key, or the before_script will prompt for it.
As a final step, add the public key from the one you created earlier to the services that you want to have an access to from within the build environment. If you are accessing a private GitLab repository you must add it as a deploy key.
After generating the key, try to sign in to the remote server to accept the fingerprint:
Verifying the SSH host keys
It is a good practice to check the private server’s own public key to make sure you are not being targeted by a man-in-the-middle attack. If anything suspicious happens, you notice it because the job fails (the SSH connection fails when the public keys don’t match).
To find out the host keys of your server, run the ssh-keyscan command from a trusted network (ideally, from the private server itself):
If you must connect to multiple servers, all the server host keys must be collected in the Value of the variable, one key per line.
Example project
We have set up an Example SSH Project for your convenience that runs on GitLab.com using our publicly available shared runners.
Want to hack on it? Fork it, commit, and push your changes. In a few moments the changes is picked by a public runner and the job starts.
Help & feedback
Product
Feature availability and product trials
Get Help
If you didn’t find what you were looking for, search the docs.
If you want help with something specific and could use community support, post on the GitLab forum.
For problems setting up or using this feature (depending on your GitLab subscription).