Git как настроить ssh

4.3 Git на сервере — Генерация открытого SSH ключа

Как отмечалось ранее, многие Git-серверы используют аутентификацию по открытым SSH-ключам. Для того чтобы предоставить открытый ключ, каждый пользователь в системе должен его сгенерировать, если только этого уже не было сделано ранее. Этот процесс аналогичен во всех операционных системах. Сначала вам стоит убедиться, что у вас ещё нет ключа. По умолчанию пользовательские SSH ключи сохраняются в каталоге ~/.ssh домашнем каталоге пользователя. Вы можете легко проверить наличие ключа перейдя в этот каталог и посмотрев его содержимое:

$ cd ~/.ssh $ ls authorized_keys2 id_dsa known_hosts config id_dsa.pub

Ищите файл с именем id_dsa или id_rsa и соответствующий ему файл с расширением .pub . Файл с расширением .pub — это ваш открытый ключ, а второй файл — ваш приватный ключ. Если указанные файлы у вас отсутствуют (или даже нет каталога .ssh ), вы можете создать их используя программу ssh-keygen , которая входит в состав пакета SSH в системах Linux/Mac, а для Windows поставляется вместе с Git:

$ ssh-keygen -o Generating public/private rsa key pair. Enter file in which to save the key (/home/schacon/.ssh/id_rsa): Created directory '/home/schacon/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/schacon/.ssh/id_rsa. Your public key has been saved in /home/schacon/.ssh/id_rsa.pub. The key fingerprint is: d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 schacon@mylaptop.local

Сначала программа попросит указать расположение файла для сохранения ключа ( .ssh/id_rsa ), затем дважды ввести пароль для шифрования. Если вы не хотите вводить пароль каждый раз при использовании ключа, то можете оставить его пустым или использовать программу ssh-agent . Если вы решили использовать пароль для приватного ключа, то настоятельно рекомендуется использовать опцию -o , которая позволяет сохранить ключ в формате, более устойчивом ко взлому методом подбора, чем стандартный формат.

Теперь каждый пользователь должен отправить свой открытый ключ вам или тому, кто администрирует Git-сервер (подразумевается, что ваш SSH-сервер уже настроен на работу с открытыми ключами). Для этого достаточно скопировать содержимое файла с расширением .pub и отправить его по электронной почте. Открытый ключ выглядит примерно так:

$ cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3 Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx NrRFi9wrf+M7Q== schacon@mylaptop.local

Более подробное руководство по созданию SSH-ключей и конфигурации клиента на различных системах вы можете найти в руководстве GitHub.

SSH и удалённые git-репозитории

Предыдущая статья была посвящена «связке» git + gpg . В этой же речь пойдёт о том, как при помощи протокола ssh удобно и безопасно работать с удалёнными git-репозиториями.

Кто этот ваш ssh?

SSH (Secure SHell) — это сетевой протокол, посредством которого два компьютера могут взаимодействовать и обмениваться данными. Важно, что данные при этом шифруются, поэтому протокол ssh считается безопасным.

С помощью ssh можно подключаться к удаленным серверам, выполнять на них команды, копировать и редактировать файлы.

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

Доступ к удалённым репозиториям

Зачем?

С 13 августа 2021 года GitHub убрал возможность использовать личный пароль для получения доступа к репозиториям по https из терминала. Вместо пароля от аккаунта на github.com при выполнении команд git clone , git fetch , git pull , или git push теперь необходимо указывать персональный токен доступа. Такое решение было принято с целью защиты пользователей и предотвращения использования злоумышленниками похищенных или взломанных паролей.

На мой взгляд, доступ к удалённым репозиториям по https (не важно — по паролю или по токену доступа) проигрывает в удобстве и гибкости доступу по ssh. При этом настройка подключения по ssh займёт у вас совсем немного времени — возможно, даже меньше, чем уйдёт на то, чтобы разобраться с токенами в GitHub. Именно поэтому я перешёл на использование ssh для всех удалённых репозиториев (расположенных не только на GitHub) даже раньше, чем GitHub перешёл на использование токенов вместо паролей.

Как?

Теперь рассмотрим конкретные шаги, которые необходимо выполнить, чтобы настроить работу с удалёнными репозиториями при помощи ssh. Я буду показывать все действия в терминале Linux.

Получаем ssh-ключи

Если у вас уже имеется пара ключей, которые вы хотите использовать для доступа к удалённым репозиториям, убедитесь, что файл с приватным ключом имеет права доступа rw——- и при необходимости установите их командой:

chmod 600 ~/.ssh/personal_key

Если у вас ещё нет пары ssh-ключей (приватного и публичного), их необходимо сгенерировать при помощи утилиты ssh-keygen .

ssh-keygen -t ed25519

Через флаг -t задаём алгоритм, на основе которого будут сгенерированы ключи. GitHub, GitLab и Yandex рекомендуют использовать ed25519 .

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

Далее по желанию можно задать пароль на генерируемый ключ. Если вы сделаете это, ssh будет требовать его при каждом использовании ключа. Чтобы не вводить пароль каждый раз, можно немного настроить ssh-agent — менеджер ключей для ssh.

После чего в терминал будет выведено «изображение» вашего ключа из ASCII-символов (красивое), а в папке ~/.ssh/ появятся два файла: id_ed25519 и id_ed25519.pub с приватным и публичным ключами соответственно. Для удобства работы эти файлы можно переименовать:

mv ~/.ssh/id_ed25519 ~/.ssh/personal_key mv ~/.ssh/id_ed25519.pub ~/.ssh/personal_key.pub

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

Чтобы ssh мог автоматически использовать правильные ключи при работе с удалёнными репозиториями, необходимо задать некоторые настройки. А именно — добавить в файл ~/.ssh/config следующие строки:

Host github.com HostName github.com User git IdentityFile ~/.ssh/personal_key IdentitiesOnly yes

• gihub.com — url сервиса, с которым будем работать (указываем одинаковым в Host и HostName ).
• ~/.ssh/personal_key — путь до файла с приватным ключом, который необходимо использовать для подключения.

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

Указываем публичный ключ на GitHub

Для того чтобы GitHub (или иной сервис) мог авторизовать ваше подключение, необходимо указать в настройках аккаунта публичный ssh-ключ, который вы будете использовать для доступа к репозиториям (также можно указать несколько ключей).

На github.com эта процедура делается следующим образом:

1. Переходим в «Settings» ->«SSH and GPG keys» (прямая ссылка).
2. Нажимаем «New SSH key».
3. В поле «Key» вставляем содержимое файла personal_key.pub (либо id_ed25519.pub , если вы не переименовывали файлы).
4. Нажимаем «Add SSH key».

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

При первом подключении по ssh необходимо будет добавить github.com (либо адрес того сервиса, который вы используете) в список доверенных хостов:

The authenticity of host 'github.com (140.82.121.4)' can't be established. RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'github.com' (RSA) to the list of known hosts. Everything up-to-date

Готово! Теперь вы можете использовать ssh для доступа к удалённым репозиторям.

Имейте в виду, что при использовании протокола ssh пути до ваших удалённых репозиториев будет отличаться от путей, которые соответствовали протоколу https. Чтобы склонировать репозиторий с GitHub по ssh, вам нужно будет выбрать вкладку «ssh» в меню клонирования репозитория, после чего использовать указанный путь аналогично обычному «https-пути» (например, указать в качестве аргумента команды git clone ).

Как сменить адрес удалённого репозитория

Если у вас уже есть репозиторий, синхронизация которого с удалённым сервером происходила по протоколу https, а теперь вы хотите использовать ssh, вам необходимо будет сменить адрес удалённого репозитория, выполнив следующую команду в локальном репозитории:

git remote set-url origin git@serviceurl:username/reponame.git

• serviceurl — url сервиса, на котором находится удалённый репозиторий (например, github.com или gitlab.com ).
• username — ник владельца репозитория.
• reponame — название репозитория.

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

git remote -v 

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

origin git@serviceurl:username/reponame.git (fetch) origin git@serviceurl:username/reponame.git (push)

с путями до вашего удалённого репозитория, значит, всё сделано правильно.

Полезные ссылки

• Видео «Как правильно настроить SSH для GitHub / GitLab»
• Статья «Как работать с несколькими GitHub-аккаунтами на своей локальной машине»
• Статья «Как эффективно работать с несколькими SSH-ключами»
• Статья «Протокол SSH и авторизация с помощью ключей»
• GitHub docs: «Connecting to GitHub with SSH»

Выводы

Используйте протокол ssh для доступа к удалённым git-репозиториям. Это безопасно и удобно!

Как добавить SSH ключ в git #

Achtung! Когда клонируем репозиторий, система предлагает ввести пароль, например:git@gitlab.example.com password:. Это указывает на то, что-то не так с локальной настройкой SSH. Убедитесь, что была правильно сгенерирована пара ключей SSH и добавлен общедоступный SSH ключ к вашему профилю GitLab.

1. Проверка на наличие OpenSSH:

Чтобы просмотреть версию SSH, установленную в системе, необходимо запустить следующую команду:

ssh -V

Поддерживаемые типы ключей SSH (доп. информация):

Для связи с GitLab можно использовать следующие типы ключей SSH:

-ED25519

-ЮАР

-АСС (Устаревшее в GitLab 11.0.)

-ECDSA (Как отмечено в Практической криптографии с Go, проблемы безопасности, связанные с DSA, также применимы к ECDSA.)

ED25519 ключи SSH

Книга Практическая криптография с Go предполагает, что ED25519 ключи более безопасны и производительны, чем ключи RSA.

OpenSSH 6.5 представил SSH-ключи ED25519 в 2014 году, и они должны быть доступны в большинстве операционные системы.

Ключи RSA SSH

Доступная документация предполагает, что ED25519 более безопасен, чем RSA.

Если используется ключ RSA, национальный институт науки и технологий США в публикации 800-57 Часть 3 (PDF) рекомендует размер ключа не менее 2048 бит. Размер ключа по умолчанию зависит от версии ssh-keygen.

2. Посмотрите, есть ли существующая пара ключей SSH:

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

В Windows, Linux или macOS перейдите в домашний каталог. Перейти к .ssh/ подкаталог. Если .ssh/ подкаталог не существует, либо не находитесь в домашнем каталоге, либо не использовали ssh. В последнем случае необходимо сгенерировать пару ключей SSH.

Важно: Если не отображается папка .ssh, значит нужно включить отображение скрытых файлов(папок) при помощи сочетаний клавиш ctrl+H.

Посмотрите, существует ли файл одного из следующих форматов:

Алгоритм #

RSA (размер ключа не менее 2048 бит)

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

Вы можете подключиться к репозиториям Git средствами SSH в macOS, Linux или Windows для безопасного подключения с помощью проверки подлинности HTTPS.

URL-адреса SSH изменились, но старые URL-адреса SSH продолжают работать. Если вы уже настроили SSH, обновите удаленный URL-адрес до нового формата:

Актуальные URL-адреса SSH начинаются с ssh.dev.azure.com . Предыдущие URL-адреса используются vs-ssh.visualstudio.com .

• Проверьте, какие удаленные серверы используют SSH. Запустите git remote -v в оболочке или используйте вместо этого клиент GUI.
• Посетите репозиторий в Интернете и выберите «Клонировать«.
• Выберите SSH и скопируйте новый URL-адрес SSH .
• В оболочке выполняется git remote set-url для каждого удаленного репозитория, который требуется обновить. Кроме того, используйте клиент графического интерфейса для обновления удаленный URL-адрес.

Как работает проверка подлинности ключа SSH

Проверка подлинности открытого ключа SSH работает с асимметричной парой созданных ключей шифрования. Открытый ключ предоставляется совместно с Azure DevOps и используется для проверки первоначального подключения ssh. Закрытый ключ хранится в безопасности и безопасности в системе.

Настройка проверки подлинности ключа SSH

Ниже описана настройка проверки подлинности ключа SSH на следующих платформах с помощью командной строки (также называемой shell ):

• Linux
• macOS
• Системы Windows под управлением Git для Windows

По состоянию на Visual Studio 2017 SSH можно использовать для подключения к репозиториям Azure DevOps Git.

В Windows мы рекомендуем использовать диспетчер учетных данных Git или личные маркеры доступа.

Шаг 1. Создание ключей SSH

Если вы уже создали ключи RSA SSH в системе, пропустите этот шаг и настройте ключи SSH. Чтобы проверить это, перейдите в домашний каталог и просмотрите папку .ssh ( %UserProfile%\.ssh\ в Windows или ~/.ssh/ linux, macOS и Windows с помощью Git Bash). Если вы видите два файла с именем id_rsa и id_rsa.pub соответственно продолжите настройку ключей SSH.

Чтобы использовать аутентификацию на основе ключей, необходимо заранее создать для клиента одну или несколько пар открытого и закрытого ключей. ssh-keygen.exe используется для создания файлов ключей и можно указать алгоритмы DSA, RSA, ECDSA или Ed25519. Если алгоритм не указан, используется RSA.

Единственным типом ключа SSH, поддерживаемым Azure DevOps, является RSA.

Чтобы создать файлы ключей с помощью алгоритма RSA, выполните следующую команду из PowerShell или другой оболочки, например bash на клиенте:

ssh-keygen 

Выходные данные команды должны отображать следующие выходные данные (где username заменяется вашим именем пользователя):

Generating public/private rsa key pair. Enter file in which to save the key (C:\Users\username/.ssh/id_rsa): 

Можно нажать клавишу ВВОД, чтобы принять вариант по умолчанию, или указать путь и (или) имя файла для создания файлов ключей. На этом этапе вам будет предложено указать парольную фразу для шифрования файлов закрытого ключа. Парольная фраза может быть пустой, но не рекомендуется. Парольная фраза в сочетании с файлом ключа позволяет выполнить двухфакторную аутентификацию.

Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in C:\Users\username/.ssh/id_rsa. Your public key has been saved in C:\Users\username/.ssh/id_rsa.pub. The key fingerprint is: SHA256:FHK6WjcUkcfQjdorarzlak1Ob/x7AmqQmmx5ryYYV+8 username@LOCAL-HOSTNAME The key's randomart image is: +---[RSA 3072]----+ | . ** o | | +.o= . | | . o+ | | .+. . | | .ooS . | | . .oo.=.o | | =.= O.= . | | . B BoE + . . | | . *+*o. .o+ | +----[SHA256]-----+ 

Теперь у вас есть пара ключей public/private rsa в указанном расположении. Файлы PUB являются открытыми ключами, а файлы без расширения — закрытыми.

Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 10/11/2022 6:29 PM 2610 id_rsa -a---- 10/11/2022 6:29 PM 578 id_rsa.pub 

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

Шаг 2. Добавление открытого ключа в Azure DevOps

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

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

1. Откройте параметры безопасности, перейдя на веб-портал и выбрав значок рядом с аватаром в правом верхнем углу пользовательского интерфейса. Выберите открытые ключи SSH в появившемся меню.
2. Щелкните + Создать ключ.
3. Скопируйте содержимое открытого ключа (например, id_rsa.pub ), созданное в поле данных открытого ключа.

Важно! Избегайте добавления пробелов или новых строк в поле «Ключевые данные «, так как они могут привести к тому, что Azure DevOps использует недопустимый открытый ключ. При вставке в ключ в конце часто добавляется новая строка. Не забудьте удалить эту новую линию, если она возникает.

На странице обзора заметка отображается в верхней части, содержащей отпечатки пальцев сервера. Запишите их, так как они будут необходимы при первом подключении к Azure DevOps через SSH.

ssh -T git@ssh.dev.azure.com 

The authenticity of host 'ssh.dev.azure.com ()' can't be established. RSA key fingerprint is SHA256:ohD8VZEXGWo6Ez8GSEJQ9WpafgLFsOfLOtGGQCQo6Og. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? 

remote: Shell access is not supported. 

ssh -T git@ssh.dev.azure.com 

The authenticity of host 'ssh.dev.azure.com ()' can't be established. RSA key fingerprint is SHA256:ohD8VZEXGWo6Ez8GSEJQ9WpafgLFsOfLOtGGQCQo6Og. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? 

remote: Shell access is not supported. 

git clone git@ssh.dev.azure.com:v3/fabrikam-fiber/FabrikamFiber/FabrikamFiber 

Cloning into 'FabrikamFiber'. Enter passphrase for key '/c/Users/username/.ssh/id_rsa': remote: Azure Repos remote: Found 127 objects to send. (50 ms) Receiving objects: 100% (127/127), 56.67 KiB | 2.58 MiB/s, done. Resolving deltas: 100% (15/15), done. 

Unable to negotiate with port 22: no matching host key type found. Their offer: ssh-rsa 

Host ssh.dev.azure.com vs-ssh.visualstudio.com HostkeyAlgorithms +ssh-rsa 

Unable to negotiate with port 22: no matching MAC found. Their offer: hmac-sha2-256,hmac-sha2-512 

Host ssh.dev.azure.com vs-ssh.visualstudio.com MACs +hmac-sha2-512,+hmac-sha2-256 

Unable to negotiate with 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256 

Host ssh.dev.azure.com vs-ssh.visualstudio.com KexAlgorithms +diffie-hellman-group-exchange-sha256,+diffie-hellman-group14-sha1,+diffie-hellman-group1-sha1 

ssh-keygen -l -E md5 -f ~/.ssh/id_rsa.pub 

git remote set-url origin

Host ssh.dev.azure.com IdentityFile ~/.ssh/id_rsa_azure IdentitiesOnly yes 

remote: Public key authentication failed. fatal: Could not read from remote repository. 

remote: Public key authentication failed. fatal: Could not read from remote repository. 

# The settings in each Host section are applied to any Git SSH remote URL with a # matching hostname. # Generally: # * SSH uses the first matching line for each parameter name, e.g. if there's # multiple values for a parameter across multiple matching Host sections # * "IdentitiesOnly yes" prevents keys cached in ssh-agent from being tried before # the IdentityFile values we explicitly set. # * On Windows, ~/.ssh/your_private_key maps to %USERPROFILE%\.ssh\your_private_key, # e.g. C:\Users\\.ssh\your_private_key. # Imagine that we have the following two SSH URLs: # * git@ssh.dev.azure.com:v3/Fabrikam/Project1/fab_repo # * For this, we want to use `fabrikamkey`, so we'll create `devops_fabrikam` as # a Host alias and tell SSH to use `fabrikamkey`. # * git@ssh.dev.azure.com:v3/Contoso/Project2/con_repo # * For this, we want to use `contosokey`, so we'll create `devops_contoso` as # a Host alias and tell SSH to use `contosokey`. # # To set explicit keys for the two host aliases and to tell SSH to use the correct # actual hostname, add the next two Host sections: Host devops_fabrikam HostName ssh.dev.azure.com IdentityFile ~/.ssh/private_key_for_fabrikam IdentitiesOnly yes Host devops_contoso HostName ssh.dev.azure.com IdentityFile ~/.ssh/private_key_for_contoso IdentitiesOnly yes 

Host ssh.dev.azure.com vs-ssh.visualstudio.com PubkeyAcceptedKeyTypes +ssh-rsa