Проблема в том, что пытаясь залепить push в репу из личного проекта система подхватывает рабочий публичный ключ (т.к. она уже работала с этим сервером) и соответсвенно не пускает меня с левым ключём в частный репозиторий.
Выходы есть такие:
- Можно добавить рабочий ключ в список допущенных в личном репозитории, но! Страдает приватность, т.к. на работе мало ли кто имеет доступ к ПК и вообще.
- Можно убирать рабочий ключ и заливать в папку ~/.ssh/ свой и потом менять - ну это понятно не наш метод. Да и забыть можно ключь свой на работе, что тоже не кошерно.
В файл ~/.ssh/config добавляем описания хостов
Host GitQnub Hostname=codaset.com IdentityFile=/media/truecrypt1/qnub Host GitWork Hostname=codaset.com IdentityFile=~/.ssh/work/work
Как видно рабочие ключи нужно также перенести из папки ~/.ssh т.к. она по умолчанию просматривается системой на предмет наличия ключей.
Соответственно IdentityFile это путь к ключу для данного репозитория (свой и рабочий). Остаётся только заменить домен Hostname в параметре url файла .git/config вашего проекта на значение Host.
Пример:
Было:
[remote "origin"] url = git@codaset.com:work/work-project.git
Стало:
[remote "origin"] url = git@GitWork:work/work-project.git
После этого команды git fetch, git push и git pull будут использовать назначенные ключи для назначенных репозиториев. Аналогичная штука работает и с github.
> Можно добавить рабочий ключ в список допущенных в личном репозитории, но! Страдает приватность, т.к. на работе мало ли кто имеет доступ к ПК и вообще
ОтветитьУдалитьдык ключик сделать с паролем и всего делов
> После этого команды git fetch, git push и git pull будут использовать назначенные ключи для назначенных репозиториев. Аналогичная штука работает и с github.
ОтветитьУдалитьА Вы в этом уверены?
Как-то, при попытке закоммитить изменения оно мне так ненавязчиво предложило проверить имя и мыло, что немудрено, ибо изменения коммитнулись почему-то все равно от моего домашнего гитаккаунта.. ЧЯДНТ?