Как настроить git через ssh linux

Доступ к bitbucket и github по ssh ключам

Если попытка склонировать любой приватный репозиторий с bitbucket или github по ssh вызывает ошибку вида:

То это значит, что вы не прошли авторизацию по ssh-ключам. Тут 2 варианта:

1. Клонировать через https схему, при этом будет запрошен имя пользователя и пароль от аккаунта. Минус тот, что при любом обращении к центральному серверу (пр. git fetch , git pull ) придётся снова вводить пароль.
2. Настроить ssh-ключи, чтобы git-аутентификация проходила автоматически без ввода паролей и т.д.

Если ключи у вас уже есть, то читайте сразу как добавить ssh ключ на github или добавить ssh ключ на bitbucket.

Рассмотрим подробнее как 1. создать ssh-ключи на linux (ubuntu) и добавить ssh ключи на 2. github и 3. bitbucket.

Генерация ssh-ключей

Для генерации ssh-ключа выполняем следующие команды:

После этого будет предложено ввести имя файла с ключами, либо если имя файла не указать, ключи будут созданы в файле id_rsa. Задаём имя файла с ключами, например, как «git_rsa«. Таким образом мы будем знать, что этот ssh-ключ используется конкретно для git-авторизации. Хотя, никто не запрещает использовать один и тот же ключ id_rsa. Ключи будут храниться в домашней директории пользователя

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

/.ssh появились 2 файла ключа:

• git_rsa — приватный, который нельзя никому сообщать
• git_rsa.pub — публичный, который мы сообщим gitbucket и github

По умолчанию при подключении к серверу для ssh-авторизации используется ключ с именем id_rsa. Мы это обойдём. Чтобы не указывать имя нужного нам ключа (git_rsa) при каждом подключении к серверу, отредактируйте файл

/.ssh/config (если файла ещё нет, создайте), добавьте содержимое для идентификации bitbucket-хоста и github:

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

Добавление ssh-ключа на github

В своём профиле нажимаем Edit Profile -> SSH Keys -> Add SSH key.

В свежем интерфейсе github:

1. кликаем на иконку профиля в правом верхнем углу, далее
2. выбираем меню Settings
3. в меню слева выбираем SSH and GPG keys
4. Жмем кнопку New SSH key.

В форме добавления ключа указываем title (это название ключа, вводится для удобства, не на что не влияет) и key (это сам ключ, т.е. вставляем сюда всё содержимое файла

/.ssh/git_rsa.pub). Нажимаем Add key.

Добавление ssh-ключа на bitbucket

Авторизуемся, заходим в свой аккаунт. Нажимаем SSH keys -> Add Key. После ввода ключа в попап окошке нажимаем кнопку Add key для сохранения ssh-ключа.

Теперь вы можете клонировать свои приватные репозитории по ssh (git@github) без ввода пароля.

На что стоит обратить внимание если ssh-авторизация по ключу все еще не работает:

• Как изменить адрес origin репозитория в git? 2 ответа
• Как сгенерировать ssh-ключи? Решено!
• git как перенести коммит из одной ветки в другую? Решено!
• Как очистить git stash? Решено!
• git удалить список тегов с сервера Решено!
• git. Настройка git 0 комментариев
• git алиасы 0 комментариев
• Отправить Pull Request в чужой репозиторий на github 0 комментариев
• Настройка прав для id_rsa (bad permissions) 0 комментариев
• Сказать git какой из ssh-ключей использовать 0 комментариев

Комментарии 5

Мне вообще уже этот «Permission denied (publickey).» всю печёнку выел!
Суть такова: есть боевой проект на jino.ru, есть репо на bitbucket-е, есть локальная версия. Сгенерил путтигеном ключи. Публичный положил на сервер в папку .ssh и добавил ключ к аккаунту на битбаккете. У себя на ПК в путти-агенте активировал приватный ключ — все должно заработать, ан нет! В путти пытаюсь запулить или запушить изменения в связке бой-битбакет — постоянно такая шняга вылезает:

«Warning: Permanently added the RSA host key for IP address ‘2406:da. e9:9f55’ to the list of known hosts.
Permission denied (publickey).»

да, на бою в папке .ssh после первого запуска пула или пуша в путти был такой запрос:

»
The authenticity of host ‘bitbucket.org (2406:da0. 2c0:3470)’ can’t be established.
RSA key fingerprint is SHA256:zzX. YXaGp1A.
RSA key fingerprint is MD5:97:8c:1. aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?
»
как я понял, что-то в стиле «подлинность битбакета не установлена, хотите ли продолжить?». Я ответил согласием, после чего создался успешно файл known_hosts (на бою в папке с ключами), куда пишется ip битбаккета (как я понимаю) и дублируется строка из ключа доступа в том виде ,в котором лежит на битбакете. На др ресурсах вычитал, что чтобы Warning не выскакивал, нужно на бю в папке с ключами положить файл config без расширения и с содержимым «UserKnownHostsFile

/.ssh/known_hosts» — сделано. Права доступа на файл ключа на бою — 600, на остальные 2 файла (конфиг и хостс) — 644, на всю папку .ssh — 700.

Что еще нужно, чтобы пул/пуш заработал по ssh. Я уже в депрессии полнейшей!)) Может для доступа к самому репо на битбакете отдельные ключи нужно добавлять? Типа, к аккаунту на битбаккете подключается, а к репе уже нет?

Amati2007, с виду вы все делаете верно!
на битбакет публичный ключ достаточно добавить только в аккаунт. Можно и отдельно в каждый репозиторий добавлять ключ, но не обязательно.

Вот еще вы пишете, что в бою при запушить возникает ошибка «Permission denied (publickey)».
1) А как вы на боевой сервер подключаетесь? Вводите пароль или авторизуетесь по тому же самому ssh ключу? Если вводите пароль, то попробуйте для начала проверить ssh-авторизацию на хостинг по тому же ключу.
2) У вас одна единственная пара ключей создана и называется id_rsa по дефолту? Чтобы убедиться что один и тот же ключ используется для коннекта, тот же что на битбакет прописан.
3) а в

/.ssh/config нет ничего лишнего? Указания на какой-то левый ключ? Для чистоты эксперимента удалить файл)
4) known_hosts удалить для чистоты эксперимента, он должен сам создаваться при первом подключении (хотя возможно еще зависит от ssh-клиента).

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

/.ssh/known_hosts и все. Изначально этого файла не было и без него всегда выдает Warning. если соединяюсь по ssh. С ним. с ним warning выдавать не должно, но выдает все равно, правда не всегда — если в путти сделать 4 раза подряд сделать попытку пуш или пулл, то этого сообщения нет. Оно появляется с 5-ой и далее попытки. И да, я еще приметил, что в тексте сообщения этого warning вторая часть (после ::) значения IP всегда разное. Например:
5-я попытка -> 2406:da00:ff00::6b17:d1f5
6-я попытка -> 2406:da00:ff00::22c2:513
7-я попытка -> 2406:da00:ff00::22c0:3470

и т.д.
То есть складывается такое ощущение, что у битбакета динамический IP, хотя, по-идее, для таких подключений должен быть набор статичных. Они даже их список где-то публиковали.
4) Да, если я удаляю known_hosts, то при попытке пула / пуша в путти вначале идет запрос про ключи The authenticity of host ‘. (полный текст я приводил в основном сообщении), а когда я отвечаю на него Yes, то known_hosts на сервере создается заново.

Ремарка: если пробовать работать с репо не по ssh, а по https, то происходит следующее: при заходе в путти по логин/паролю все успешно, при попытке пулл/пуш просит пароль — я его ввожу тот, что от аккаунта битбакета и, вуаля, меня не пускает. все тот же «Доступ запрещен», хотя локальная связка работает и я могу как принимать файлы с битбакета на локал, так и отправлять изменения обратно.

Источник

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

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2015

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

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

• Проверьте, какие удаленные службы используют SSH, выполнив git remote -v в клиенте Git.
• Откройте репозиторий в Интернете и нажмите кнопку клонировать в правом верхнем углу.
• Выберите SSH и скопируйте новый URL-адрес SSH.
• В клиенте Git выполните: git remote set-url . кроме того, в Visual Studio перейдите в репозиторий Параметрыи измените удаленные.

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

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

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

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

Следующие шаги охватывают настройку проверки подлинности ключей SSH на следующих платформах:

• Linux
• macOS, работающий по меньшей мере Leopard (10,5)
• Windows системы с Git для Windows

Настройте SSH с помощью командной строки. bash является общей оболочкой в Linux и macOS, а git для Windows установки добавляет ярлык для git Bash в меню. Другие среды оболочки будут работать, но не будут рассмотрены в этой статье.

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

Если вы уже создали ключи 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/тфс

Свяжите открытый ключ, созданный на предыдущем шаге, с ИДЕНТИФИКАТОРом пользователя.

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

Выберите + новый ключ.

Скопируйте содержимое открытого ключа (например, id_rsa. pub), созданного в поле данных открытого ключа .

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

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

Проверьте подключение, выполнив следующую команду: ssh -T git@ssh.dev.azure.com . Если все работает правильно, вы получите ответ, который говорит: remote: Shell access is not supported. Если нет, см. раздел с вопросами и устранением неполадок.

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

Свяжите открытый ключ, созданный на предыдущем шаге, с ИДЕНТИФИКАТОРом пользователя.

Откройте параметры безопасности, перейдя на веб-портал и выбрав аватар в правом верхнем углу интерфейса пользователя. В появившемся меню выберите Безопасность .

Выберите + новый ключ.

Скопируйте содержимое открытого ключа (например, id_rsa. pub), созданного в поле данных открытого ключа .

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

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

Проверьте подключение, выполнив следующую команду: ssh -T git@ssh.dev.azure.com . Если все работает правильно, вы получите ответ, который говорит: remote: Shell access is not supported. Если нет, см. раздел с вопросами и устранением неполадок.

Шаг 3. Клонирование репозитория Git с помощью SSH

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

Скопируйте URL-адрес клонирования SSH с веб-портала. В этом примере URL-адрес клона SSL предназначен для репозитория в Организации с именем Fabrikam-Fiber, как указано первой частью URL-адреса после dev.azure.com .

Project url-адреса были изменены в выпуске Azure DevOps Services и теперь имеют формат dev.azure.com// , но можно использовать существующий visualstudio.com формат. дополнительные сведения см. в разделе Visual Studio Team Services теперь Azure DevOps Services.

Выполните git clone в командной строке.

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

SSH отображает этот отпечаток при подключении к неизвестному узлу и защищает вас от атак типа «злоумышленник в середине». Приняв отпечаток узла, SSH не выводит запрос повторно, пока отпечаток не изменится.

Когда появится запрос на продолжение подключения, введите yes . Git будет клонировать репозиторий и настроить удаленный доступ origin для подключения по протоколу SSH для будущих команд git.

чтобы избежать проблем, Windows пользователи должны выполнить команду , чтобы Git повторно использовал парольную фразу SSH.

Вопросы и устранение неполадок

Вопрос. После выполнения git clone я получаю следующую ошибку. Что следует делать?

Ответ . Вручную запишите ключ SSH, выполнив команду: ssh-keyscan -t rsa domain.com >>

Вопрос. как с помощью Git запоминать парольную фразу для моего ключа на Windows?

Ответ . выполните следующую команду, входящую в Git, чтобы Windows запустить ssh-agent процесс в PowerShell или в Windows командной строке. ssh-agent кэширует вашу парольную фразу, чтобы не указывать ее при каждом подключении к репозиторию.

Если вы используете оболочку Bash (включая Git bash), запустите ssh-agent с:

Вопрос. я использую в качестве моего клиента SSH ввод и создал ключи с помощью PuTTYgen. Можно ли использовать эти ключи с Azure DevOps Services?

Ответ. Да. Загрузите закрытый ключ с помощью PuTTYgen, перейдите в меню преобразования и выберите Экспорт ключа OpenSSH. Сохраните файл закрытого ключа и выполните действия по настройке ключей, не относящихся к по умолчанию. Скопируйте открытый ключ непосредственно из окна PuTTYgen и вставьте в поле Data ( Ключевые данные ) в параметры безопасности.

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

Ответ . Отпечаток открытого ключа, который отображается в профиле, можно проверить с помощью следующей ssh-keygen команды, выполняемой для открытого ключа в bash командной строке. Если значения по умолчанию не используются, необходимо будет изменить путь и имя файла открытого ключа.

Затем можно сравнить сигнатуру MD5 с той, которая есть в вашем профиле. Эта проверка полезна при возникновении проблем с подключением или при неправильном вводе открытого ключа в поле данных ключа при добавлении ключа в Azure DevOps Services.

Вопрос. как начать использовать SSH в репозитории, где сейчас используется протокол HTTPS?

Ответ . Вам потребуется обновить origin Удаленный в Git, чтобы изменить URL-адрес HTTPS на SSH. Получив URL-адрес клона SSH, выполните следующую команду:

Теперь можно выполнить любую команду git, которая подключается к origin .

вопрос. я использую Git LFS с Azure DevOps Services и получаю сообщения об ошибках при получении файлов, отслеживаниющих с помощью Git LFS.

ответ . Azure DevOps Services сейчас не поддерживает LFS через SSH. Используйте HTTPS для подключения к репозиториев с отслеживанием файлов LFS Git.

Вопрос. как использовать расположение ключа не по умолчанию, т. е. not/.СШ/id_rsa и

Ответ . Чтобы использовать ключи, созданные ssh-keygen в, в другом месте, отличном от используемого по умолчанию, выполните следующие две задачи:

1. Ключи должны находиться в папке, которую можно читать или изменять. Если у папки есть более широкие разрешения, SSH не будет использовать эти ключи.
2. Необходимо предоставить SSH сведения о расположении ключей. Вы делает SSH-доступ к ключам с помощью ssh-add команды, предоставляя полный путь к закрытому ключу.

в Windows перед запуском необходимо ssh-add выполнить следующую команду из команды, включенной в Git, для Windows:

Эта команда выполняется как в PowerShell, так и в командной строке. При использовании git Bash необходимо использовать следующие команды:

его можно найти ssh-add как часть Git для Windowsного распространения, а также запускать в любой среде оболочки на Windows.

В macOS и Linux также необходимо ssh-agent запустить перед запуском ssh-add , но среда команд на этих платформах обычно начинает с самого начала ssh-agent .

Вопрос. у меня несколько ключей 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 (

замените именем узла Azure DevOps или сервера TFS, например tfs.mycompany.com .

Вопрос. какие уведомления могут получать сведения о ключах SSH?

Ответ . при регистрации нового ключа ssh с Azure DevOps Services вы получите уведомление по электронной почте о том, что в учетную запись добавлен новый ключ ssh.

Вопрос. что делать, если я полагаю, что кто-то, помимо меня, добавляет ключи SSH в мою учетную запись?

Ответ . Если вы получили уведомление о регистрации SSH-ключа и вы не перегрузили его в службу вручную, возможно, ваши учетные данные были скомпрометированы.

Следующий шаг — выяснить, не был ли ваш пароль скомпрометирован. Изменение пароля всегда является хорошим первым шагом для защиты от этого вектора атак. если вы являетесь Azure Active Directory пользователем, обратитесь к администратору, чтобы проверить, использовалась ли ваша учетная запись из неизвестного источника или расположения.

Вопрос. что делать, если у меня по-прежнему запрашиваются пароль и GIT_SSH_COMMAND=»ssh -v» git fetch отображается no mutual signature algorithm ?

Ответ . некоторые дистрибутивы linux, например Fedora Linux, имеют политики шифрования, требующие более строгих алгоритмов подписи SSH, чем поддерживает Azure DevOps (по состоянию на январь 2021). Есть запрос на открытие функции для добавления этой поддержки.

Можно обойти эту ошибку, добавив следующий код в конфигурацию SSH (

Источник