Подключение к серверу gitosis через туннель SSH

У меня есть настройка туннеля SSH на моем macbook, вроде этого...

$ ssh -o ServerAliveInterval=3 -N -L 22222:gitosis-server:22 [email protected]

Итак, я могу ssh на localhost: 22222 и попаду на gitosis-сервер за брандмауэром.

Я создал локальный файл id_rsa.pub, скопировал его на сервер gitosis (работает Centos5) и импортировал его в gitosis, используя...

 # sudo -H -u gitosis gitosis-init

Это было успешно, так как я вижу открытый ключ в /var/lib/gitosis/.ssh/authorized_keys.

Назад на моем macbook Я setup файл ~/.ssh/config со следующим...

Host gitosis-server
Hostname localhost
HostKeyAlias gitosis-server.domain.com
  Port 22222

Итак... Я думаю, что эта команда должна работать...

$ git clone [email protected]:gitosis-admin.git

В то же время он не запрашивает пароль... когда открытые ключи должны работать.

Initialized empty Git repository in /Users/USER/Development/gitrepo/gitosis-admin/.git/
[email protected] password:

Любые идеи о том, как заставить git работать с сервером gitosis за брандмауэром?

Спасибо,
Matt

EDIT - добавление отладки из попытки SSH

Я сделал эту команду: 'ssh -vvv gitosis @gitosis-server'. Я получаю отладку назад, и мне это не похоже на мою идентификацию.

debug2: key: /Users/USER/.ssh/id_rsa.gitosis (0x1019b0)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/USER/.ssh/id_rsa.gitosis
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected] password:

РЕДАКТИРОВАТЬ 2

ОК... Определенно плохой ключ. Я дважды проверил все свои ключи и, конечно же, обнаружил, что gitosis-сервер держит плохой ключ в файле authorized_keys.

debug1: userauth-запрос для пользователя gitosis service ssh-connection method none debug1: попытка 0 сбоев 0 debug1: PAM: инициализация для "gitosis" debug1: PAM: настройка PAM_RHOST на "firewall.domain.com" debug1: PAM: установка PAM_TTY на "ssh" debug1: userauth-запрос для пользователя gitosis service ssh-connection method publickey debug1: попытка 1 сбой 1 debug1: проверить, приемлемы ли pkalg/pkblob debug1: temporarily_use_uid: 102/103 (e = 0/0) debug1: поиск файла открытого ключа /var/lib/gitosis/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 102/103 (e = 0/0) debug1: поиск файла открытого ключа /var/lib/gitosis/.ssh/authorized_keys2 debug1: restore_uid: 0/0 Не удалось опубликовать публикацию для gitosis от FIRE.WALL.IP.ADDRESS порт 52453 ssh2

Я более подробно рассмотрел файл authorized_keys на сервере gitosis... и это было неправильно. Я дважды проверил файл открытого ключа, который я скопировал в /tmp с моей рабочей станции, и он был правильным, но отличается от того, что было в authorized_keys. Я удалил файл authorized_keys на сервере и повторно запустил 'sudo -H -u gitosis gitosis-init </tmp/id_rsa.gitosis.pub. Еще раз проверьте файл authorized_keys..... и все еще было не так.

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

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

Мне нравится, что gitosis запоминает первый ключ, который я там вложил.... и не позволяю мне изменить его на исправленный.

Срыв...

Matt

ОТВЕТЫ

Ответ 1

Followup:

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

Итак, сегодня я просто удалил и переустановил пакет gitosis на моем ящике CentOS5. 

yum удалить гитоз
rm -rf/var/lib/gitosis
yum install gitosis
sudo -H -u gitosis gitosis-init </tmp/id_rsa.gitosis.pub   # правильный ключ

На моем Mac я прохожу через SSH туннель localhost: 22222 через брандмауэр на gitosis-server: 22. 

 $ssh -o ServerAliveInterval = 3 -N -L 22222: gitosis-server: 22 [email protected]

На моем Mac я создал ~/.ssh/config, который выглядит так... 

 Host gitosis-server
Имя хоста localhost
IdentityFile ~/.ssh/id_rsa.gitosis
HostKeyAlias ​​gitosis-server.domain.com Порт 22222

Затем... следуя инструкциям на этом сайте...

http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

... все после... "Здесь происходит какая-то крутая магия. Запустите это на своей локальной машине:" ... просто работает... за исключением того, что вместо имени пользователя "w20" > "с" гитозом ".

Надеюсь, что эта глупость поможет кому-то. Спасибо также за предложения, которые я получил здесь. Это помогло сузить проблему.

Matt

Ответ 2

Это проблема ssh и не проблема (git).

ssh -v - ваш друг, поскольку он даст вам отладочную информацию о том, какие методы проверки подлинности и ключи ssh пытается использовать.

Девять раз из десяти я нахожу, что это проблема с разрешениями на ключевые файлы. ssh вам нравится ваш каталог .ssh, а ваш id_rsa файл должен быть записан только пользователем, а мой umask по умолчанию позволяет записывать файлы группы. ssh -v расскажет вам, если это так в вашей ситуации.

Edit

Это похоже на то, что сервер sshd не принимает вашу личность. Я не знаю, есть ли у вас доступ к удаленному серверу, но может работать сервер sshd в режиме отладки.

Выполнение чего-то подобного позволяет одно соединение на данном порту (чтобы оно не прерывало обычную службу sshd) и выводило информацию об отладке. Это может помочь отладить, почему серверу не нравится ваша личность.

sshd -d -p 2022

Если ваша "нормальная" служба sshd запускается с дополнительными параметрами, обязательно отправьте их в отладочную версию.

Ответ 3

Моя настройка для аналогичной ситуации (работает)

У меня есть аналогичная настройка для repo.or.cz (которая по какой-то причине отключена NCP-маршрутом, используемым ISP, польским ISP Telekomunikacja SA (tpnet)), и он работает для меня:

Я запускаю следующий запуск команды для настройки SSH-туннеля перед попыткой подключения:

$ autossh -M 20000 -f -N -L 2222:repo.or.cz:22 [email protected]

(Я использую autossh вместо ssh для повторного подключения, если я отсоединен, т.е. поддерживать соединение). Убедитесь, что в SSH-агент аутентификации добавлены соответствующие идентификаторы:

$ ssh-add -l
2048 d7:d3:69:f5:0f:f9:5e:aa:e0:0b:28:c2:03:42:09:66 /home/user/.ssh/id_dsa_gateway.example.com (DSA)
1024 11:a2:29:fe:37:12:a7:33:c4:23:b0:e1:82:92:e0:6a /home/user/.ssh/id_dsa_repo.or.cz (DSA)

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

У меня есть следующая настройка в моем ~/.ssh/config:

Host repo.or.cz
        # NoHostAuthenticationForLocalhost yes
        HostName localhost
        Port 2222

Эта настройка работает для меня без проблем.

Отладка вашей ситуации

Что касается отладки вашей ситуации?

Во-первых, я бы проверил, могу ли я войти на шлюз, используя "ssh [email protected]", чтобы проверить, можно ли настроить туннель SSH. Если вы работаете в Linux, вы можете использовать, например, netstat --tcp, чтобы проверить, установлено ли соединение для шлюза; в других операционных системах и средах вы можете найти похожие утилиты.

Проверьте, можете ли вы правильно подключиться к гитоз. (Если я правильно помню gitorious использует gitosis для управления доступом через SSH, поэтому я использовал ответ от gitorious в примере ниже)

$ ssh [email protected]
Need SSH_ORIGINAL_COMMAND
                             Connection to  closed.

Если он не делает что-то похожее на предыдущее (repo.or.cz возвращает "фатальный": "Как вы думаете, я?", GitHub возвращает "Привет, пользователь!" Вы успешно прошли аутентификацию, но GitHub делает не предоставлять доступ к оболочке. "), проверьте, где он сбой с" ssh -v gitosis @gitosis-server ":

$ ssh -v [email protected]
[...]
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_dsa_gitosis-server
debug1: Remote: Forced command: gitosis-server user
[...]
debug1: Authentication succeeded (publickey)

Ответ 4

Вы говорите, что можете успешно выполнить ssh до localhost:2222. Чтобы убедиться, что вы правильно настроили ~/.ssh/config, можете ли вы ssh просто gitosis-server?

ssh gitosis-server

Ответ 5

У меня была аналогичная проблема, и я решил ее с помощью:

[[email protected] ~]$ echo $SSH_AUTH_SOCK
/tmp/keyring-KXX3Aw/ssh
[[email protected] tmp]$ sudo rm -rf keyring-KXX3Aw/

Возможно, ваши ключи были кешированы там?