Git ssh настройка linux
Обновлено: 06.07.2024
Если попытка склонировать любой приватный репозиторий с bitbucket или github по ssh вызывает ошибку вида:
То это значит, что вы не прошли авторизацию по ssh-ключам. Тут 2 варианта:
Если ключи у вас уже есть, то читайте сразу как добавить 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:
- кликаем на иконку профиля в правом верхнем углу, далее
- выбираем меню Settings
- в меню слева выбираем SSH and GPG keys
- Жмем кнопку New SSH key.
В форме добавления ключа указываем title (это название ключа, вводится для удобства, не на что не влияет) и key (это сам ключ, т.е. вставляем сюда всё содержимое файла
/.ssh/git_rsa.pub). Нажимаем Add key.
Добавление ssh-ключа на bitbucket
Авторизуемся, заходим в свой аккаунт. Нажимаем SSH keys -> Add Key. После ввода ключа в попап окошке нажимаем кнопку Add key для сохранения ssh-ключа.
Теперь вы можете клонировать свои приватные репозитории по ssh (git@github) без ввода пароля.
На что стоит обратить внимание если ssh-авторизация по ключу все еще не работает:
- на ключ id_rsa не должно быть слишком много прав
- у вас создано несколько ssh-ключей и нужно дать понять какой из ключей использовать
Комментарии 5
"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-клиента).
Вообще, судя по ошибке, не нравится именно ключ: проверить что на битбакет залит нужный ключ. Может, стоит сгенерить новый ключ и проверить заново (старый удалить).
root, спасибо, что пытаетесь мне помочь!1) На боевой я положил публичный ключ и назвал его authorized_keys согласно п.4 инструкции по добавлению на сервер ключей ssh от хостера (https://jino.ru/help/faq/ssh/ssh-key-auth/). То есть ,если этого ключа на боевом сервере нет, то при запуске путти просит указать и логин и пароль. Если же этот ключ там лежит, то путти просит ввести логин, а затем выдает строку Authenticating with public key "rsa-key-20201109" from agent, из которой можно понять, что авторизация по ключам с сервером успешна.
2) Да, я проводил чистый эксперимент - удалил все ключи с пк, с сервера и с битбаккета, перегенерировал их через puttygen и вновь все разложил (сохраненный публичный положил на боевой под названием файла authorized_keys, строку из самого путтигена - на битбакет (название файла ключа там необязательное поле, но я ввел такое же ,как на боевом), приватный подключил в puttyagent).
Ремарка: если пробовать работать с репо не по ssh, а по https, то происходит следующее: при заходе в путти по логин/паролю все успешно, при попытке пулл/пуш просит пароль - я его ввожу тот, что от аккаунта битбакета и, вуаля, меня не пускает. все тот же "Доступ запрещен", хотя локальная связка работает и я могу как принимать файлы с битбакета на локал, так и отправлять изменения обратно.
Давайте рассмотрим настройку доступа по SSH на стороне сервера. В этом примере мы будем использовать метод authorized_keys для аутентификации пользователей. Мы подразумеваем, что вы используете стандартный дистрибутив Linux типа Ubuntu.
Вместо ручного копирования и установки открытых ключей, многое из описанного ниже может быть автоматизировано за счёт использования команды ssh-copy-id .
Для начала создадим пользователя git и каталог .ssh для этого пользователя:
Затем вам нужно добавить открытые SSH-ключи разработчиков в файл authorized_keys пользователя git . Предположим, у вас уже есть несколько таких ключей и вы сохранили их во временные файлы. Напомним, открытый ключ выглядит примерно так:
Вы просто добавляете их в файл .ssh/authorized_keys в домашнем каталоге пользователя git :
Теперь вы можете создать пустой репозиторий для них, запустив git init с параметром --bare , что инициализирует репозиторий без рабочего каталога:
Теперь все остальные могут клонировать его и отправлять в него изменения:
Этим способом вы можете быстро получить Git-сервер с доступом на чтение/запись для небольшой группы разработчиков.
Заметьте, что теперь все эти пользователи могут заходить на сервер как пользователь git . Чтобы это предотвратить, нужно изменить ему оболочку на что-то другое в файле /etc/passwd .
Вы можете легко ограничить пользователя git только действиями, связанными с Git, с помощью ограниченной оболочки git-shell , поставляемой вместе с Git. Если указать её в качестве командного интерпретатора для пользователя git , то он не сможет получить доступ к обычной командной оболочке на вашем сервере. Для её использования, укажите git-shell вместо bash или csh для пользователя git . Для этого вы должны сначала добавить git-shell в /etc/shells если её там ещё нет:
Теперь можно изменить оболочку для пользователя используя chsh <username> -s <shell> :
Теперь пользователь git может использовать SSH соединение только для работы с репозиториями Git и не может зайти на машину. Если вы попробуете войти в систему, то вход будет отклонён:
На текущий момент пользователи всё ещё могут использовать перенаправление порта SSH для доступа к другим Git серверам, к которым текущий может подключиться. Если это нужно отключить, вы можете добавить следующие опции в файл authorized_keys перед теми ключами, для которых нужно применить это ограничение:
В результате файл будет выглядеть следующим образом:
Материал, перевод которого мы сегодня публикуем, посвящён настройке Git-серверов. Git — это система управления версиями, разработанная Линусом Торвальдсом. Git пользуются миллионы людей во всём мире. Компании, вроде GitHub, предлагают службы хостинга кода, основанные на Git. По информации, которую можно найти в различных публикациях, GitHub является крупнейшим сервисом для хостинга IT-проектов. В частности, в 2017-м году сообщество GitHub достигло 24 миллионов разработчиков, которые трудятся над 67 миллионами репозиториев. В наши дни GitHub пользуются абсолютно все — от программистов-одиночек, до крупных организаций. Надо сказать, что даже компания Google перешла на GitHub, закрыв собственный проект схожей направленности.
Зачем нужен собственный Git-сервер?
GitHub — это замечательный сервис, но, особенно если вы — индивидуальный разработчик или небольшая компания, вы, при работе с GitHub, столкнётесь с некоторыми ограничениями. Одно из них заключается в том, что в бесплатный пакет услуг не входит хостинг приватных репозиториев. За эту возможность придётся заплатить, как минимум, $7 в месяц.
В подобных ситуациях, для того, чтобы обойти ограничения, или если вам нужно контролировать то, что происходит с вашими репозиториями, лучше всего создать собственный Git-сервер. Это, с одной стороны, поможет сэкономить, а с другой — даст полный контроль над сервером. Среди продвинутых пользователей Linux весьма распространена практика использования собственных Git-серверов, размещаемых, можно сказать, бесплатно, на уже используемых ими серверах.
В этом руководстве мы поговорим о двух подходах к управлению кодовой базой с использованием собственного Git-сервера. Первый заключается в использовании обычного Git-сервера, а второй — в применении инструмента с графическим интерфейсом GitLab. В качестве платформы для экспериментов тут используется сервер на полностью пропатченной Ubuntu 14.04 LTS, развёрнутый на VPS.
Использование Git
Здесь мы рассматриваем сценарий, в соответствии с которым у нас имеется удалённый сервер и локальный сервер. Работаем мы периодически то с одним, то с другим.
Для начала установим Git на этих двух машинах. Git можно установить либо из пакета, доступного в репозитории используемого дистрибутива, либо вручную. Тут мы воспользуемся простейшим методом:
Затем добавим пользователя для Git:
Для того чтобы упростить доступ к удалённому серверу, настроим вход по ssh без пароля.
Создадим ssh-ключи на локальном компьютере:
Система спросит у вас о том, куда нужно сохранить ключ. Если вас устраивает стандартное место хранения ключа, просто нажмите Enter. Далее вам предложат задать пароль, который будет нужен для доступа к удалённому серверу.
Вышеописанная команда генерирует два ключа — открытый и закрытый. Запишите или запомните расположение открытого ключа. Он понадобится нам на следующем шаге.
Теперь надо скопировать эти ключи на сервер, что даст возможность наладить канал связи между двумя машинами. На локальном компьютере выполните следующую команду:
Теперь подключитесь по ssh к серверу и создайте директорию проекта для Git. Для репозитория можно использовать любую папку, которая покажется вам подходящей:
Затем перейдите в эту директорию:
Создайте пустой репозиторий:
Теперь нужно создать Git-репозиторий на локальной машине. Для этого создаём директорию:
Переходим в неё:
Далее, создаём в ней файлы проекта, и, оставаясь в ней, инициализируем репозиторий:
Теперь добавим файлы проекта в репозиторий:
В нашем случае здесь имеется файл, который называется GoT (в нём лежит текст обзора Game of Thrones), в который внесены некоторые изменения. Изменения внесены и в другой файл. Поэтому при выполнении команды система сообщила о том, какие изменения были внесены в файлы. В вышеописанной команде опция -a означает обработку всех файлов репозитория. Если вы внесли изменения лишь в один файл, можно, вместо опции -a , указать имя этого файла.
Теперь можно отправлять изменения с локальной машины на сервер или загружать данные с сервера, используя, соответственно, опции push или pull :
Если над проектом намереваются работать и другие программисты, сначала им надо клонировать репозиторий с сервера на своих локальных компьютерах:
В данной команде /home/swapnil/project.git — это путь к папке проекта на удалённом сервере, в вашем случае тут будет другой путь.
Затем, после клонирования, надо перейти в директорию проекта:
У вас, вместо project будет имя другой директории. Теперь можно приступать к работе над проектом, принимать изменения и отправлять их на сервер:
Мы полагаем, что вышеприведённых сведений достаточно для того, чтобы помочь тем, у кого не было опыта работы с Git, приступить к использованию собственного Git-сервера. Если вам нужен некий инструмент с графическим интерфейсом, позволяющий работать с проектом на локальной машине, можно воспользоваться чем-то вроде QGit или GitK для Linux.
QGit — графический инструмент для локальной работы с Git-репозиториями
Использование GitLab
Выше мы описали систему, позволяющую организовать совместную работу над проектами с помощью Git, полностью основанную на средствах командной строки. Работать в такой среде, конечно, сложнее, чем с GitHub. По иронии судьбы, хотя GitHub — это крупнейший в мире сервис для хостинга кода, его собственный код закрыт. Это — не опенсорсный проект, то есть, нельзя взять этот код и создать на его основе собственный GitHub. В отличие от чего-то вроде WordPress и Drupal, код GitHub нельзя загрузить и развернуть на собственном сервере.
Но, как это обычно бывает в мире опенсорса, проектам с закрытым кодом можно найти замену. В данном случае заменой GitHub может послужить весьма привлекательный опенсорсный проект GitLab. Он позволяет всем желающим разворачивать на собственных серверах нечто подобное GitHub. При этом GitLab можно использовать и для поддержки работы крупной компании или большой команды, и для организации собственного репозитория для небольшого проекта, который пока не готов к тому, чтобы представить его широкой общественности.
GitLab задействует бизнес-модель, характерную для опенсорсных проектов. А именно, имеется свободно распространяемая версия ПО, которую все желающие могут разворачивать на своих серверах, и хостинг кода, похожий на GitHub.
Среди возможностей GitLab можно отметить управление Git-репозиториями, средства обзора кода, наличие системы отслеживания ошибок, ленты активности, поддержку вики-страниц. Здесь имеется и GitLab CI — система непрерывной интеграции.
Многие VPS-провайдеры, вроде DigitalOcean, предлагают пользователям дроплеты GitLab. Если вы хотите развернуть GitLab на собственном сервере, вы можете установить эту систему вручную. GitLab предлагает пакет Omnibus для различных операционных систем. Прежде чем установить GitLab, может возникнуть необходимость в настройке почтового SMTP-сервера для того, чтобы система могла отправлять электронную почту. Рекомендовано для этих целей пользоваться Postfix. Поэтому, перед установкой GitLab, установим Postfix:
В процессе установки Postfix система задаст вам несколько вопросов. Не стоит пропускать ответы на них, но если ответы на них не даны, можно перенастроить систему, выполнив следующую команду:
После запуска этой команды нужно указать параметр Internet Site и задать почтовый идентификатор для домена, который будет использоваться GitLab. Далее, надо будет указать имя пользователя для Postfix и почтовый адрес. Значения остальных параметров можно не менять. После установки и настройки Postfix можно заняться GitLab.
Загрузим свежий пакет отсюда с помощью wget :
Теперь установим его:
Настроим и запустим GitLab:
Теперь надо будет настроить доменное имя в конфигурационном файле, что даст возможность работать с GitLab. Откроем файл:
В этом файле надо будет отредактировать параметр external_url , указав здесь доменное имя сервера. После редактирования файла его надо сохранить, после чего только что созданный GitLab-сайт можно открыть в браузере.
Сайт GitLab, открытый в браузере
По умолчанию система создаёт учётную запись администратора с именем root и паролем 5iveL!fe . Сразу после первого входа на сайт следует поменять пароль.
Смена пароля на сайте GitLab
После того, как пароль изменён, можно войти на сайт и заняться работой с проектами.
Работа с проектами в GitLab
GitLab — это серьёзная система, имеющая массу возможностей. Как в них разобраться? Позволим себе привести тут несколько изменённую цитату из фильма «Матрица»: «Увы, невозможно рассказать о том, что умеет GitLab. Вы должны увидеть это сами».
Как настроить подключение к удаленному Git-репозиторию, через SSH, на компьютере с Windows 7 . И соответственно выкачать содержимое к себе на локальный сервер.
Удаленный репозиторий находится на сервере с git. мне нужно просто склонировать содержимое. никаких пушей обратно. там есть идентификация. сгенерил паблик кей и отослал спец-ту на той стороне. как мне добавить ранее сгенеренный-свой ключ через консоль и подключиться к серверу? какие команды. Windows 7 на моей машине.
Установка
Если ещё не установлен, то Git можно взять здесь. Вместе с ним будет unix-like консоль Git Bash.
Клонирование через SSH
Пример команды для клонирования через SSH.
В общем случае команда для клонирования по SSH выглядит так:
Создание ssh-ключа.
На Windows можно как через cmd, так и Git Bash, на *nix — просто в консоли. Но в cmd я не разбираюсь, поэтому привожу инструкцию только для Git Bash & *nix:
Можно выбрать passphrase, который повышает надёжность, но его нужно будет вводить каждый раз при использовании. Если забудете — ключ бесполезен для дальнейшего использования.
После выполнения команды публичный ключ появляется соответственно в
Именно публичный ключ нужно передавать специалисту на той стороне. (Наверняка вы так и сделали, но всё-таки стоит об этом сказать)
Если всё сделали правильно, то при попытке соединения по ssh ключ будет использоваться автоматически.
Если ключ уже есть
То его надо положить в c:\Users\%username%\.ssh . Если имя ключа отличается от id_rsa , то надо создать файл c:\Users\%username%\.ssh\config со следующим содержимым:
В ней полностью показаны клиентские программы для работы с push-ом и pull-ом. У меня лично Windows недолюбливал родной Git клиент, но всегда прекрасно работает с Tortoise (есть в статье).
В ней есть полное руководство по подключению. Не уверен правильная ли это аналогия, но вы можете поставить себе программу Composer и ей подобные, после чего можно через консоль Windows полностью клонировать себе репозиторий с Git-а.
Добавил, как попросили, кратко содержимое статьи:
Я рекомендую выбрать "Run Git from the Windows Command Prompt". Все остальные опции можно оставлять по-умолчанию. После установки Git нужно перегрузиться или завершить сеанс пользователя и снова войти, чтобы применились изменения в системной переменной PATH.
Далее нужно проверить, доступен ли Git для работы. В любом каталоге даем команду:
Если получаем информацию о версии, то 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. Это делается следующими командами, которые можно выполнить, находясь в любом каталоге:
После этих настроек, можно заливать свои файлы в репозитарий. Переходим в каталог со своим проектом, и даем команды:
После этих команд на сервере GitHub образуется копии файлов того каталога, в котором были выполнены данные команды. Далее можно уже делать коммиты, заливки на сервер GitHub изменений, считывания изменений с сервера. Но это уже совсем другая история.
Читайте также: