Назад | Перейти на главную страницу

Невозможно получить доступ к репозиторию gitosis с локального компьютера. получает сообщение «Permission denied (publickey)».

Я пытаюсь настроить сервер Git на сервере Debian, но не могу добавить пользователей, которые могут успешно получить к нему доступ.

После выполнения gitosis-init, клонирования репозитория gitosis-admin и добавления открытого ключа локальной машины в каталог / keydir и редактирования файла gitosis.conf я фиксирую и нажимаю. Именно об этом мне говорят многие учебники.

Я подтвердил, что репозиторий gitosis-admin был обновлен правильно, путем клонирования его в другое место, и обновления были сделаны.

gitosis.conf

[gitosis]

[group gitosis-admin]
writable = gitosis-admin
members = saifis@debian, saifis@local

Теперь я пытаюсь клонировать gitosis-admin в файл на моем локальном компьютере, и это дает

Permission denied (publickey).

ошибка.

ssh -v gitosis @ DebianAddress дает мне

OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to 192.168.xxx.xxx [192.168.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /Users/saifis/.ssh/identity type -1
debug1: identity file /Users/saifis/.ssh/id_rsa type 1
debug1: identity file /Users/saifis/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /Users/saifis/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
-----------------
debug1: Trying private key: /Users/saifis/.ssh/identity
debug1: Trying private key: /Users/saifis/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

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

Если потребуется дополнительная информация, заполните меня.

--- Добавлено ---- О ~ / gitosis / .ssh / authorized_keys. Насколько я понимаю, поскольку авторизованные пользователи git получают доступ через SSH через учетную запись gitosis, добавление открытого ключа в authorized_keys действительно звучит как правильный ответ, однако в верхней части файла он имеет

### autogenerated by gitosis, DO NOT EDIT

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

Я думал, что gitosis позаботился об этом и предоставил доступ только при доступе с помощью методов git, а не прямого доступа ssh, или они все равно добавляются в authorized_keys?

Прежде чем вы что-нибудь нажмете, единственный ключ, имеющий права на учетную запись gitosis, - это тот, который вы передали в gitosis-init. То, что другие ключи имеют доступ к вашей учетной записи обычного пользователя, не имеет значения. Сравните ключ в ~gitosis/.ssh/authorized_keys и ssh-add -L.


Gitosis работает так: при каждом нажатии запускается обработчик post-update, и gitosis восстанавливает authorized_keys для своей учетной записи. Если он не получил ваш ключ, скорее всего, он был не в том формате, который ожидает gitosis. Поскольку перехватчик является пост-обновлением, обновление будет принято, даже если оно было недействительным (gitosis мог бы быть более строгим, имея как перехватчик обновления, так и перехватчик пост-обновления). Внесите тривиальное изменение и нажмите еще раз с хоста, у которого есть начальный ключ, чтобы просмотреть сообщения об ошибках gitosis. Добавление ключа в authorized_keys вручную включает в себя дублирование правильной строки, замену типа ключа, данных ключа и имени пользователя.