после обновления до удаленного живого сервера ssh и проблемы с веткой master - PullRequest
1 голос
/ 21 июня 2011

У меня есть ситуация, когда из-за ограничений размера я не могу разместить пустой репозиторий на том же сервере, что и конкретный веб-сайт. Итак, я установил пустой репозиторий на сервере A, который я тоже хочу перенести в основную ветку, когда рад, что обновление хорошее. В перехвате / пост-обновлении он должен подключиться к работающему серверу по ssh и вытянуть ветку master.

Я сгенерировал открытый ключ ssh на работающем сервере, авторизовал его и скопировал открытый ключ в файл /var/www/.ssh/authorized_keys на голом сервере репо. В основном все сделано на этом сайте здесь

Но при попытке аутентификации на работающем сервере происходит сбой.

Пост-обновление выглядит так:

ssh liveuser@liveserver.com

cd cd/path/to/site/.git || exit
git pull bare master
exit

Я получаю это сообщение

$ git push server master
userForBare@www.ServerAAddress.com's password:
Counting objects: 5, done.
Delta compression using up to 3 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 279 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
remote:
remote: *** Pulling changes into Live [Live's post-update hook] ***
remote:
remote: Permission denied, please try again.
remote: Permission denied, please try again.
remote: Permission denied (publickey,gssapi-with-mic,password).
remote: fatal: The remote end hung up unexpectedly
To ssh://userForBare@www.ServerAAddress.com/var/git/websiteToUpdate.git
   b251909..883d129  master -> master

1 Ответ

0 голосов
/ 21 июня 2011

Вы, кажется, запускаете git pull на live, что означает, что live вернется в www.ServerAAddress.com.Таким образом, есть 2 sshs, которые должны использовать открытый ключ без пароля для аутентификации, и один из них не авторизован правильно:

  1. ssh из «A» («bare») в «live» нуждается в приватномключ (.ssh/id*), хранящийся в «A», и открытый ключ (в .ssh/authorized_keys) в «live».
  2. ssh из «live» обратно в «A» (внутри git pull) требуется личныйключ хранится в «живом» и открытый ключ в «A».Ключи должны быть разными.

Места на серверах, вероятно, разные.Файлы в «A» должны быть в доме userForBare, в то время как файлы в «live» должны быть в доме www пользователя.

Искать в журналах (ssh обычно входит в /var/log/auth или /var/log/security) и убедитесь, что он на самом деле находит открытые ключи, которые он и хочет прочитать:

  • Многие настройки будут не иметь /var/www как $HOME пользователя www, поэтому вам может потребоваться поместить .ssh/authorized_keys в другом месте.
  • ssh отказывается читать что-либо $HOME/.ssh/, если файл или любая директория работаетВ root могут записываться все, кроме этого пользователя или root, поэтому, если, например, /var/www доступен для записи в группе, ssh отклонит /var/www/.ssh/authorized_keys как возможно скомпрометированный.
...