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

У меня на MacBook настроен SSH-туннель, вот так...

$ ssh -o ServerAliveInterval = 3 -N -L 22222: сервер gitosis:22 user@firewall.domain.com 

Так что я могу SSH к localhost:22222 и в конечном итоге на Gitosis-сервере за брандмауэром.

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

 # sudo -H -u gitosis gitosis-init

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

Вернувшись в свой macbook, я установил файл ~/.ssh/config со следующим...

 Хост-гитоз-сервер
Имя хоста localhost
HostKeyAlias ​​gitosis-server.domain.com
  Порт 22222

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

 $ git clone gitosis@ gitosis-server: gitosis-admin.git 

Однако это не так, поскольку возникает вопрос о пароле... когда должны работать открытые ключи.

 Инициализированный пустой репозиторий Git в /Users/USER/Development/gitrepo/gitosis-admin/.git/
Gitosis@ пароль локального хоста: 

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

Спасибо,
Matt


РЕДАКТИРОВАТЬ - Добавление отладки из попытки SSH

Я сделал эту команду, 'ssh -vvv gitosis@gitosis-server'. Я получаю некоторую отладку назад, и мне не нравится моя идентичность.

debug2: ключ: /Users/USER/.ssh/id_rsa.gitosis (0x1019b0)
debug1: аутентификации, которые могут продолжаться: publickey, gssapi-with-mic, пароль
debug3: начать заново, передал другой список publickey, gssapi-with-mic,password
debug3: предпочтительная публичная клавиша, клавиатура-интерактив, пароль
debug3: authmethod_lookup publickey
debug3: оставаясь предпочтительным: клавиатура-интерактив, пароль
debug3: authmethod_is_enabled publickey
debug1: следующий метод аутентификации: publickey
debug1: предложение открытого ключа: /Users/USER/.ssh/id_rsa.gitosis
debug3: send_pubkey_test
debug2: мы отправили пакет publickey, ждем ответа
debug1: аутентификации, которые могут продолжаться: publickey, gssapi-with-mic, пароль
debug2: мы не отправляли пакет, отключите метод
debug3: пароль authmethod_lookup
debug3: оставаясь предпочтительным:, пароль
debug3: пароль authmethod_is_enabled
debug1: следующий метод аутентификации: пароль
Gitosis@ пароль локального хоста: 

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

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

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

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

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

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

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

Разочарование...

Matt

5 ответов

Решение

Следовать за:

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

Поэтому сегодня я только что удалил и переустановил пакет с gitosis на моем CentOS5-боксе.

ням удалить гитоз
rm -rf /var/lib/gitosis
ням установить гитоз
sudo -H -u gitosis gitosis-init # правильный ключ

На моем Mac я SSH туннель localhost:22222 через брандмауэр к gitosis-серверу: 22.

 $ ssh -o ServerAliveInterval = 3 -N -L 22222: сервер gitosis:22 user@firewall.domain.com 

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

 Хост-гитоз-сервер
Имя хоста 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

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

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

Matt

Это ssh выдавать, а не (пока) git вопрос.

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

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

редактировать

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

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

sshd -d -p 2022

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

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

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

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

$ autossh -M 20000 -f -N -L 2222:repo.or.cz:22 user@gateway.example.com

(Я использую 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)

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

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

Хост repo.or.cz
        # NoHostAuthenticationForLocalhost yes
        HostName localhost
        Порт 2222

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


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

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

Во-первых, я бы проверил, могу ли я войти в шлюз с помощью "ssh user@firewall.domain.com", чтобы проверить, можно ли настроить SSH-туннель. Если вы используете Linux, вы можете использовать, например, netstat --tcp проверить, установлено ли соединение с шлюзом; в других операционных системах и средах вы можете найти аналогичные утилиты.

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

$ ssh gitosis @ gitosis-server
Нужно SSH_ORIGINAL_COMMAND
                             Подключение к закрытому.

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

$ ssh -v gitosis @ gitosis-server
[...]
debug1: аутентификации, которые могут продолжаться: publickey
debug1: следующий метод аутентификации: publickey
debug1: предложение открытого ключа: /home/user/.ssh/id_dsa_gitosis-server
debug1: Remote: принудительная команда: пользователь gitosis-сервера
[...]
debug1: аутентификация прошла успешно (publickey)

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

ssh gitosis-server

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

[srydberg@zeus ~]$ echo $SSH_AUTH_SOCK
/tmp/keyring-KXX3Aw/ssh
[srydberg@zeus tmp]$ sudo rm -rf keyring-KXX3Aw/

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

Другие вопросы по тегам