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.
Настройка git для работы через ssh

Это нужно, чтобы не теребить ssh-agent и ssh-add. Так хост будет автоматически понимать какой ключ использовать.
Создаем или редактируем ~/.ssh/config . Прописываем следующее:
Host github.com HostName github.com IdentityFile ~/.ssh/github
Если ~/.ssh/config не существовал, то может потребоваться ввести chmod 600 ~/.ssh/config .
Сообщаем о нашем ключе GitHub’у
- Смотрим сам ключ: cat ~/.ssh/github.pub , копируем его в буфер обмена
- Открываем https://github.com/settings/keys, добавляем туда скопированный ключ. Название не важно
Заставляем репозиторий работать через ssh, а не логин-токен
Если раньше вы писали git clone https://github.com/USER_NAME/REPO_NAME.git , то теперь будет git clone git@github.com:USER_NAME/REPO_NAME.git
$ git clone git@github.com:USER_NAME/REPO_NAME.git $ git clone https://github.com/USER_NAME/REPO_NAME.git
Может быть полезно:
- Вот тут я писал про SSH ключи в целом. Почему они на самом деле проще, чем пароли
- Если вы на винде и используете Putty, Kitty, то это может стать хорошей заменой
Ну и на главной странице есть другая всячина
Как настроить подключение к удаленному Git репозиторию
Как настроить подключение к удаленному Git-репозиторию, через SSH, на компьютере с Windows 7 . И соответственно выкачать содержимое к себе на локальный сервер. Удаленный репозиторий находится на сервере с git. мне нужно просто склонировать содержимое. никаких пушей обратно. там есть идентификация. сгенерил паблик кей и отослал спец-ту на той стороне. как мне добавить ранее сгенеренный-свой ключ через консоль и подключиться к серверу? какие команды. Windows 7 на моей машине.
Отслеживать
33.9k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака
задан 23 ноя 2015 в 10:35
Intermediate Intermediate
139 1 1 золотой знак 1 1 серебряный знак 5 5 бронзовых знаков
@NickVolynkin удаленный репозиторий находится на сервере с git. мне нужно просто склонировать содержимое. никаких пушей обратно. там есть идентификация. сгенерил паблик кей и отослал спец-ту на той стороне. как мне добавить ранее сгенеренный-свой ключ через консоль и подключиться к серверу? какие команды. Windows 7 на моей машине.
23 ноя 2015 в 12:22
@NickVolynkin разобрался. остался 1 вопрос. как через консоль добавить ssh ключ, который был ранее создан. не через веб-интерфейс, а именно через консоль
23 ноя 2015 в 14:01
к себе в гит. на удаленный сервер я передал спец-ту. он добавил. у меня при подключении не цепляется ключ. вот поэтому я и спрашиваю
23 ноя 2015 в 14:18
@Abyx благодарю)
23 ноя 2015 в 14:41
3 ответа 3
Сортировка: Сброс на вариант по умолчанию
Установка
Если ещё не установлен, то Git можно взять здесь. Вместе с ним будет unix-like консоль Git Bash.
Клонирование через SSH
Пример команды для клонирования через SSH.
git clone [email protected]:brockgr/csshx.git
В общем случае команда для клонирования по SSH выглядит так:
git clone [email protected]:user/reponame.git
Не перепутайте с HTTPS, который потребует авторизации через логин-пароль:
git clone https://github.com/brockgr/csshx.git
Создание ssh-ключа.
На Windows можно как через cmd, так и Git Bash, на *nix — просто в консоли. Но в cmd я не разбираюсь, поэтому привожу инструкцию только для Git Bash & *nix:
Можно выбрать passphrase, который повышает надёжность, но его нужно будет вводить каждый раз при использовании. Если забудете — ключ бесполезен для дальнейшего использования.
После выполнения команды публичный ключ появляется соответственно в
C:\Users\%username%\.ssh\id_rsa.pub ~/.ssh/id_rsa.pub
Именно публичный ключ нужно передавать специалисту на той стороне. (Наверняка вы так и сделали, но всё-таки стоит об этом сказать)
Если всё сделали правильно, то при попытке соединения по ssh ключ будет использоваться автоматически.
Если ключ уже есть
То его надо положить в c:\Users\%username%\.ssh . Если имя ключа отличается от id_rsa , то надо создать файл c:\Users\%username%\.ssh\config со следующим содержимым:
Host: server.domain IdentityFile путь_и_имя_ключа
Отслеживать
ответ дан 23 ноя 2015 в 13:36
Nick Volynkin ♦ Nick Volynkin
33.9k 25 25 золотых знаков 130 130 серебряных знаков 222 222 бронзовых знака
На практике мне когда-то помогла эта статья — лучший пример из всего что я видел: http://habrahabr.ru/sandbox/37865/
В ней полностью показаны клиентские программы для работы с push-ом и pull-ом. У меня лично Windows недолюбливал родной Git клиент, но всегда прекрасно работает с Tortoise (есть в статье).
В ней есть полное руководство по подключению. Не уверен правильная ли это аналогия, но вы можете поставить себе программу Composer и ей подобные, после чего можно через консоль Windows полностью клонировать себе репозиторий с Git-а.
Если же касается более специфичного подключения именно к Git, то эта страница будет полезной: http://webhamster.ru/site/page/index/articles/comp/171
Добавил, как попросили, кратко содержимое статьи:
Идем на официальную страницу Git http://git-scm.com, кликаем на Download for Windows. В открывшемся окне кликаем на Full installer for official Git. Запускаем полученный exe-шник.
Я рекомендую выбрать «Run Git from the Windows Command Prompt». Все остальные опции можно оставлять по-умолчанию. После установки Git нужно перегрузиться или завершить сеанс пользователя и снова войти, чтобы применились изменения в системной переменной PATH.
Далее нужно проверить, доступен ли Git для работы. В любом каталоге даем команду:
git --version
Если получаем информацию о версии, то Git установлен и работает. Если получаем информацию что программа git не найдена, разбираемся что сделали не так.
Настройка SSH-ключей в Windows
В операционной системе Windows генератор SSH-ключей включен в комплект поставки Git. Для генерации ключей необходимо запустить на выполнение файл C:\Program Files\Git\Git bash.vbs. Его можно запустить как обычный exe-шник. Откроется программа «Консоль git». В ней надо дать команду:
Будьте внимательны, в этой консоли подглючивает копи-паст, проще ввести команду вручную. В качестве email указываем свой почтовый ящик. На запрос «Enter file in which to save the key» просто нажимаем Enter. При запросе пароля «Enter passphrase» и «Enter same passphrase again» просто нажимаем Enter. В процессе генерации ключей в консоли будет выдаваться примерно следующая информация:
После выполнения этой программы, в каталоге C:\Documents and Settings\username.ssh будут лежать файлы id_rsa и id_rsa.pub, они нам пригодятся в дальнейшем.
Установка SSH-ключа в GitHub
Нас колько я помню, эта часть ответа несколько изменилась в современном дизайне GitHub-а, но интуитивно можо найти.
Сразу после регистрации необходимо прописать в системе GutHub свой публичный ключ шифрования (открытый SSH-ключ). Для добавления ключа, надо в правом верхнем углу нажать «Account Settings».
В открывшемся окне нужно кликнуть на пункт меню «SSH Public Keys», и нажать «Add Another Public Key». Появится два поля — название ключа (Title) и содержимое ключа (Key).
В поле Title можно написать название компьютера, на котором сгенерирован публичный ключ. Можно писать по-русски.
В поле Key надо вставить содержимое файла id_rsa.pub . Помните, в каком каталоге они находятся? Переходим в этот каталог, открываем любым текстовым редактором файл id_rsa.pub (именно с расширением .pub , не перепутайте). Выделяем весь текст, копируем, и вставляем на странице GitHub в поле Key.
После добавления ключа, компьютер может соединяться с GitHub через программу git, и никаких ошибок не должно возникать.
Работа с репозитарием на GitHub через программу Git
Начиная с этого момента, пляски вокруг web-интерфейса GitHub можно считать законченными. Далее можно работать только используя программу git.
Вначале нужно сделать небольшую настройку программы git: указать локальной системе git имя пользователя и email. Это делается следующими командами, которые можно выполнить, находясь в любом каталоге:
где вместо YourFullName нужно написать свое имя, а вместо [email protected] — свой email. Эти значения используются для логина на GitHub. Поэтому на месте YourFullName нужно указать ваш логин на GitHub-е, а на месте [email protected] нужно указать email, который вы вводили при генерации ключей шифрования.
После этих настроек, можно заливать свои файлы в репозитарий. Переходим в каталог со своим проектом, и даем команды:
git init git add . git commit -a -m 'first commit' git remote add origin [email protected]:username/reponame.git git push -u origin master
После этих команд на сервере GitHub образуется копии файлов того каталога, в котором были выполнены данные команды. Далее можно уже делать коммиты, заливки на сервер GitHub изменений, считывания изменений с сервера. Но это уже совсем другая история.
Настройка доступа по SSH к нескольким профилям на GitHub с одного компьютера

При любом сохранении данных из локального Git-репозитория в репозиторий на GitHub (например, при выполнении команды git push) сервер проводит аутентификацию пользователя, чтобы понять, кто именно к нему обращается. При этом можно каждый раз с клавиатуры вводить своё имя и пароль, под которыми мы регистрировались на GitHub, но гораздо удобнее один раз настроить аутентификацию по ключам SSH. После этого процедура проверки подлинности будет проходить незаметно для нас, никакие дополнительные пароли вводить не придётся.
Если вы работаете на GitHub только с одним профилем, то настроить аутентификацию по ключам SSH совсем несложно (далее мы подробно рассмотрим, как это делается). Но иногда бывает необходимо заходить в GitHub под разными пользователями (например, одна учётная запись для личных проектов, а другая – для рабочих). Как в этом случае избавиться от надоедливого ввода пароля при каждом сохранении изменений в удалённом репозитории?
В этой статье мы покажем, как настроить аутентификацию по SSH-ключам для работы с разными профилями на GitHub с одного и того же компьютера. Для этого необходимо сделать три шага:
1. Создать SSH-ключи и настроить доступ по ним к первой учётной записи на GitHub.
2. Создать SSH-ключи и настроить доступ по ним ко второй учётной записи на GitHub.
3. Настроить SSH на работу с разными ключами в зависимости от адреса GitHub-репозитория, к которому идёт обращение.
Шаг 1. Настраиваем доступ по SSH-ключам к первому профилю
SSH (Secure Shell) – это защищённый протокол для доступа к удалённым компьютерам, находящимся в сети. Подключившись к компьютеру по SSH, мы сможем работать в оболочке командной строки, запущенной на этом компьютере. Визуально это выглядит так, что мы работаем в окне терминала на своей машине, но по факту выполняем команды на другом компьютере, который физически может находиться на расстоянии тысяч километров от нас. Для проверки подлинности пользователя используются пары SSH-ключей:
— Закрытый ключ (private key) – это файл, который создаётся и хранится на локальном компьютере. Этот файл нельзя никому передавать, его содержимое ни в коем случае не должно попасть в чужие руки!
— Открытый ключ (public key) – это файл, генерируемый совместно с закрытым ключом, который можно свободно распространять.
Закрытый и открытый ключи соответствуют друг другу, как ключ и замок. Если информация зашифрована одним из этих ключей, то расшифровать её можно только с помощью другого ключа.
В случае с GitHub это работает так: закрытый ключ хранится на вашем компьютере, а содержимое открытого ключа регистрируется в вашем профиле на сервере GitHub . Когда серверу поступает запрос на изменение в репозитории, эти ключи сравниваются, и если они соответствуют друг другу, то аутентификация пользователя считается успешной.
Процесс настройки SSH-ключей выглядит практически одинаково для любой современной операционной системы (Windows 10, macOS, Linux), за исключением путей к домашнему каталогу пользователя. Мы будем работать в Windows 10, где путь к домашнему каталогу имеет вид C:\Users\имя_пользователя (этот путь хранится в переменной среды HOMEPATH).
Генерируем пару ключей на локальной машине
Сначала на своём компьютере сгенерируем пару из открытого и закрытого ключей. Для этого откроем стандартную командную строку Windows и выполним команду ssh-keygen (в устаревших версиях Windows данная команда может отсутствовать, в этом случае команду ssh-keygen нужно запустить в оболочке Git Bash, которая устанавливается на компьютер вместе с Git):

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

Как видим, утилита ssh-keygen создала директорию .ssh в домашнем каталоге пользователя (в нашем случае это пользователь с именем andrv) и запрашивает дополнительное ключевое слово passphrase – это пароль для повышенной защиты SSH-ключей. Мы оставим его пустым, дважды нажав .

В результате в каталоге .ssh созданы два файла: id_rsa (закрытый ключ) и id_rsa.pub (открытый ключ):

Открытый ключ из файла id_rsa.pub мы должны зарегистрировать в своём профиле на GitHub. Посмотрим содержимое этого файла с помощью команды type:

Для того, чтобы записать публичный ключ на GitHub, нужно сохранить содержимое файла id_rsa.pub в буфере обмена. Для этого можно воспользоваться стандартной для Windows 10 утилитой clip, передавая ей в качестве входного потока нужный файл:

Другой вариант – открыть файл с ключом в Блокноте, выбрав его в Проводнике или выполнив команду notepad %HOMEPATH%\.ssh\id_rsa.pub, а там уже скопировать содержимое файла в буфер обмена.

Сохраняем открытый ключ в профиле на GitHub
Теперь содержимое файла id_rsa.pub, которое мы скопировали в буфер обмена, нужно сохранить в настройках своего профиля на GitHub.
Для этого зайдем на GitHub под своей учётной записью (в нашем примере это пользователь andpop), кликнем на треугольнике справа от своей аватарки в верхнем правом углу окна и в открывшемся списке выберем пункт Settings.

В открывшемся окне нужно выбрать пункт SSH and GPG keys:

Появится список SSH-ключей, которые мы регистрировали для нашей учётной записи ранее (их может быть несколько), и кнопка New SSH key для ввода нового ключа:

Для регистрации нового ключа нужно:
1. В поле Title ввести его название. Оно нужно только для информации о том, для какого компьютера вы добавили ключ, больше мы его нигде использовать не будем.
2. В поле Key вставить содержимое открытого ключа, который мы заранее сохранили в буфере обмена.

После нажатия кнопки Add SSH key GitHub может запросить ваш пароль для подтверждения регистрации нового ключа:

На этом настройка SSH-ключей для вашей первой учетной записи завершена, теперь изменения из локального репозитория будут сохраняться на GitHub без запроса имени и пароля пользователя.
Отметим, что при первом обращении к GitHub с использованием SSH-ключей в консоли вы получите такое сообщение:
The authenticity of host 'github.com (140.82.121.3)' can't be established. RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. Are you sure you want to continue connecting (yes/no/[fingerprint])?
Пугаться этого не стоит, дело в том, что при SSH-соединении не только сервер удостоверяется в подлинности клиента, но и клиент проверяет, знаком ли ему данный сервер, заходил ли он на него ранее. Поэтому при первом подключении к серверу GitHub нужно ответить yes, при этом уникальная комбинация символов, идентифицирующая сервер (RSA key fingerprint), сохранится на нашем компьютере, а сервер GitHub будет добавлен в список известных хостов. При всех последующих обращениях к GitHub этот вопрос задаваться не будет.
Шаг 2. Настраиваем ключи для второго профиля
Для второй учётной записи мы должны сгенерировать новую пару SSH-ключей. Для этого вновь воспользуемся командой ssh-keygen, указав другое имя файла для нового ключа (в нашем случае это id_rsa_work в той же директории .ssh домашнего каталога):

Теперь в каталоге %HOMEPATH%\.ssh у нас хранятся две пары SSH-ключей:

Новый публичный ключ, записанный в файле id_rsa_work.pub, нужно зарегистрировать в настройках второй нашей учётной записи на GitHub. Эта процедура полностью аналогична рассмотренной выше регистрации SSH-ключа из id_rsa_work.pub для первой учетной записи, поэтому подробно на ней мы останавливаться не будем.
Шаг 3. Настраиваем SSH на работу с двумя парами ключей
Итак, мы имеем две пары SSH-ключей для доступа к репозиториям двух пользователей GitHub:
— ключ id_rsa для личной учётной записи;
— ключ id_rsa_work для рабочей учётной записи.
Теперь в каталоге %HOMEPATH%\.ssh нужно создать конфигурационный файл с именем config и записать туда параметры подключения к серверу GitHub для каждого ключа:
# Личная учетка andpop на GitHub Host github.com HostName github.com User git AddKeysToAgent yes IdentityFile C:\Users\andrv\.ssh\id_rsa # Рабочая учетка andpop-mrsu на GitHub Host github.com-work HostName github.com User git AddKeysToAgent yes IdentityFile C:\Users\andrv\.ssh\id_rsa_work
По этим параметрам клиентский SSH-агент определит, какой именно ключ нужно использовать при обращении к ресурсам, адрес которых содержит тот или иной хост.
Чтобы понять этот механизм, посмотрим, в каком формате задаётся путь к GitHub-репозиторию при его клонировании на локальный компьютер по SSH. Зайдём, например, в репозиторий Finansist пользователя andpop, нажмём на зеленую кнопку Code и выберем вкладку SSH:

Как видим, при обращении к этому репозиторию по протоколу SSH будет использоваться следующий адрес: [email protected]:andpop/Finansist.git.
Таким образом, при доступе по SSH адрес GitHub-репозитория имеет такую структуру:
git@ хост :пользователь_GitHub / репозиторий .git
Если нам нужно работать с GitHub-репозиторием из первого профиля (пользователь andpop), то мы клонируем нужный репозиторий на локальный компьютер командой git clone, оставляя SSH-адрес без изменений:
git clone [email protected]:andpop/Finansist.git
При этом будет применен SSH-ключ id_rsa, заданный в конфигурационном файле %HOMEPATH%\.ssh\config для хоста github.com:
Host github.com HostName github.com User git AddKeysToAgent yes IdentityFile C:\Users\andrv\.ssh\id_rsa
Если же нам нужен репозиторий из второго профиля (пользователь andpop-mrsu), то при клонировании нужно в адресе репозитория к имени хоста github.com добавить префикс -work:
git clone [email protected]:andpop-mrsu/Finansist.git
В этом случае будет применен SSH-ключ id_rsa_work, заданный в конфигурационном файле %HOMEPATH%\.ssh\config для хоста github.com-work:
Host github.com-work HostName github.com User git AddKeysToAgent yes IdentityFile C:\Users\andrv\.ssh\id_rsa_work
Отметим, что адрес GitHub-репозитория, с которым связан локальный репозиторий, можно посмотреть с помощью команды git remote get-url origin. При необходимости этот адрес можно изменить командой git remote set-url origin.
Например, мы при клонировании репозитория Finansist из профиля пользователя andpop-mrsu забыли добавить префикс -work:
git clone [email protected]:andpop-mrsu/Finansist.git
Теперь при попытке «запушить» коммит в репозиторий пользователя andpop-mrsu будет применен не ключ id_rsa_work, а ключ id_rsa, который мы регистрировали для пользователя andpop. Возникнет ошибка:
ERROR: Permission to andpop-mrsu/Finansist.git denied to andpop. fatal: Could not read from remote repository.
В этом случае нужно изменить адрес GitHub-репозитория, указав в качестве хоста github.com-work:
git remote set-url origin [email protected]:andpop-mrsu/Finansis.git
После этого доступ к GitHub-репозиторию будет получен и команда git push отработает корректно.
Итак, мы научились работать по протоколу SSH с двумя разными GitHub-профилями – теперь вы можете с одного компьютера делать изменения в личных и рабочих репозиториях, не отвлекаясь на ввод имени и пароля при каждом обращении к GitHub.