Подключение к серверу 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/
Может быть, ваши ключи были там кешированы?