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

Установка открытого ключа Gitosis не работает

Я слежу этот учебник для установки и настройки git на Ubuntu Server 10.04 с использованием Windows 7 в качестве клиента. Однако, наконец выяснив, как это работает (несколько раз выполнив gitosis-init с неправильным ключом), я скопировал id_rsa.pub файл на сервер в /tmp папку и снова запустил.

К сожалению, это все еще не работает, и когда я выполняю

git clone gitosis@yourserver.com:gitosis-admin.git

он просит gitosisпароль, а не парольную фразу RSA. Я предполагаю, что это та же проблема этот парень здесь ... однако, следуя его инструкциям:

Очистите git-core и gitosis и вручную удалите папку / srv / gitosis

и после инструкции снова (на этот раз с правильным файлом id_rsa.pub), у меня все еще та же проблема.

Кто-нибудь знает, что я делаю не так? Есть ли способ получить дополнительную информацию, которая могла бы помочь в решении этой проблемы?

Редактировать: выход из ssh -vvv gitosis@{IP_ADDRESS} (Последние несколько строк показывают, где он переключается с открытого ключа на пароль):

{UserName}@{COMPUTERNAME} ~
$ ssh -vvv gitosis@{IP_ADDRESS}
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug2: ssh_connect: needpriv 0
debug1: Connecting to {IP_ADDRESS} [{IP_ADDRESS}] port 22.
debug1: Connection established.
debug1: identity file /c/Users/{UserName}/.ssh/identity type -1
debug3: Not a RSA1 key file /c/Users/{UserName}/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'Proc-Type:'
debug3: key_read: missing keytype
debug2: key_type_from_name: unknown key type 'DEK-Info:'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
# Repeated 23 times here...
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /c/Users/{UserName}/.ssh/id_rsa type 1
debug1: identity file /c/Users/{UserName}/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu6
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
# Bunch of stuff here that doesn't seem important... I can include if necessary
debug3: check_host_in_hostfile: filename /c/Users/{UserName}/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host '192.168.0.113' is known and matches the RSA host key.
debug1: Found key in /c/Users/{UserName}/.ssh/known_hosts:1
debug2: bits set: 526/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /c/Users/{UserName}/.ssh/identity (0x0)
debug2: key: /c/Users/{UserName}/.ssh/id_rsa (0xa01a428)
debug2: key: /c/Users/{UserName}/.ssh/id_rsa (0x0)
debug1: Authenications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Trying private key: /c/Users/{UserName}/.ssh/identity
debug3: no such identity: /c/Users/{UserName}/.ssh/identity
debug1: Offering public key: /c/Users/{UserName}/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /c/Users/{UserName}/.ssh/id_dsa
debug3: no such identity: /c/Users/{UserName}/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password #it just switched to password...
debug3: remaining_preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
gitosis@{IP_ADDRESS}'s password:

Согласно этому обсуждение в чате, по возможной причине:

значение HOME (правильно установлено на /C/Users/UserName)
по сравнению с оболочкой, используемой для различных команд (Cygwin, потому что он ssh-copy-id команда, в отличие от оболочки msysgit bash)

поскольку ssh-copy-id копировать только строку в файл (см. "ssh-copy-id и дубликаты в authorized_keys", было проще:

сгенерируйте ключи rsa в сеансе msysgit bash (ключи будут созданы в /c/Users/UserName/.ssh/id_rsa, snce $HOME относится к /c/Users/UserName/)
скопируйте вручную содержимое id_rsa.pub в ~/.ssh/authorized_keys сервера (поскольку здесь возможен прямой доступ к указанному серверу).

ОП user29600 исправил!

1) Убедился, что HOME был в качестве переменной среды с использованием C:\Users\UserName как путь.

2) Создал ключи RSA в MingW "ssh-keygen -t rsa"и разрешив настройку по умолчанию в имени файла и назначив правильную парольную фразу.

3) Сделал "ssh-copy-id -i $HOME/.ssh/id_rsa.pub {USER}@{SERVER_IP}"чтобы убедиться, что для этого пользователя включена аутентификация по ключу RSA. 4) отправил .pub файл на сервер, используя "

scp $HOME/.ssh/id_rsa.pub {USER}@{SERVER_IP}:/tmp

5) установил git-core и gitosis и выполнил "sudo -H -u gitosis gitosis-init < /tmp/id_rsa.pub"

6) Произошла ошибка о разрешениях на id_rsa файл при использовании MingW.
Нашел Эта статья это сказал, чтобы скопировать ssh.exe файл из C:\cygwin\bin к C:\Program Files\Git\bin и перезапишите файл, включив необходимые .dll файлы.
Этот шаг был вызван тем, что MingW неправильно устанавливал или читал chmods ... cygwin показал 600, MingW показал 644.
После копирования ssh.exe файл, я смог правильно chmod файлы с MingW и ошибка разрешения исчезли.

7) "git clone gitosis@{SERVER_IP}:gitosis-admin.git"наконец-то сработало!