Я пытаюсь настроить сервер 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 вручную включает в себя дублирование правильной строки, замену типа ключа, данных ключа и имени пользователя.