2013-09-25 4 views
1

Я пытаюсь заставить гитолит работать и застрял часами. Сервер CentOS 6 в моей локальной сети.gitolite не работает с услугой sshd

я, наконец, получил ssh -vvv gitolite работать с этим конфиге

Host gitolite 
User gitolite 
HostName srv 
Port 2002 
IdentityFile ~/.ssh/srv_gitolite_openssh 

НО он работает только тогда, когда я делаю это на сервере для отладки

sudo service sshd stop 
sudo /usr/sbin/sshd -Dd 

Когда SSHD работает как сервис , соединение не выполняется.

http://pastebin.com/UHVS1sSK

Почему это работает, когда я вручную запустить SSHd, но не с SSHD как сервис? Кажется, что используется тот же файл sshd_config, потому что он использует тот же номер порта. Кроме того, мое имя пользователя gitolite находится в части конфигурации AllowUsers.

случай успеха выглядит следующим образом:

http://pastebin.com/x4TcrG4R

Update: Вот журналы на стороне сервера

терпят неудачу в качестве услуги: http://pastebin.com/Xce2k2x5

успех: http://pastebin.com/jYgiDhEm

Основные моменты отказа ниже. Должно ли «key_from_blob» быть одинаковым в обоих случаях? Я попытался удалить часть команды authorized_keys, и она по-прежнему не работает как служба.

debug3: mm_answer_keyallowed entering 
debug3: mm_answer_keyallowed: key_from_blob: 0x7f72b6e93350 
debug1: temporarily_use_uid: 505/505 (e=0/0) 
debug1: trying public key file /var/lib/gitolite/.ssh/authorized_keys 
debug1: restore_uid: 0/0 
debug1: temporarily_use_uid: 505/505 (e=0/0) 
debug1: trying public key file /var/lib/gitolite/.ssh/authorized_keys2 
debug1: restore_uid: 0/0 
Failed publickey for gitolite from 192.168.1.201 port 57488 ssh2 
debug3: mm_answer_keyallowed: key 0x7f72b6e93350 is not allowed 
debug3: mm_request_send entering: type 22 

моменты от случая успеха:

debug3: mm_answer_keyallowed entering 
debug3: mm_answer_keyallowed: key_from_blob: 0x7f4d79de18b0 
debug1: temporarily_use_uid: 505/505 (e=0/0) 
debug1: trying public key file /var/lib/gitolite/.ssh/authorized_keys 
debug1: fd 4 clearing O_NONBLOCK 
debug3: secure_filename: checking '/var/lib/gitolite/.ssh' 
debug3: secure_filename: checking '/var/lib/gitolite' 
debug3: secure_filename: terminating check at '/var/lib/gitolite' 
debug2: key_type_from_name: unknown key type 'command="/var/lib/gitolite/bin/gitolite-shell' 
debug3: key_read: missing keytype 
debug2: user_key_allowed: check options: 'command="/var/lib/gitolite/bin/gitolite-shell gitolite",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBrEOo5blAUXXSwXdxUxTOhBDHcjw2OzxGg6Vu4drzmUYL5uPxjWLGzuzcNkrYmlVqXr5UBqeSbkZh9W/0lLMcmiv5FLdIQ+J2m5lqHsEJLS8FImfJxfo2/LvboFy0NFOxF8GaHxeIWFp+YmwAlogO9gi1zgXK99DGc15W/edYwCw== 
' 
debug1: matching key found: file /var/lib/gitolite/.ssh/authorized_keys, line 2 
Found matching RSA key: ae:92:1d:a7:7b:ec:75:7a:19:ac:28:75:b0:cc:27:8f 
debug1: restore_uid: 0/0 
debug3: mm_answer_keyallowed: key 0x7f4d79de18b0 is allowed 
+0

SELinux был в случае, 'restorecon -r -vv/var/lib/gitolite/.ssh' – Matt

ответ

1

Я подозреваю, что ключи работают в обоих случаях.

Но работает sshd как услуга отличается от работы с текущей сессией: см. «Why would I use “service sshd reload” in preference to “service sshd restart”?».

Служба отменяет все наследуемые переменные среды и сохраняет только PATH и TERM.

Gitolite uses a forced command зарегистрирован в ~gitolite/.ssh/authorized_keys, и должна отсутствовать переменная среды (когда sshd запускается как служба), которая предотвращает выполнение команды.


Был подобный случай с "public key authentication fails ONLY when sshd is daemon":

SELinux, скорее всего, причина.
.ssh Дир, вероятно, не маркирован.

Посмотрите на /var/log/audit/audit.log. Он должен быть помечен как ssh_home_t.
Обратитесь к ls -laZ. Run restorecon -r -vv /root/.ssh при необходимости.

+0

Спасибо за те подсказки относительно того, что может быть другим. Есть ли журналы, на которые я могу посмотреть, чтобы получить больше советов? Я думаю, что у меня довольно стандартный init.d/sshd (я ничего не изменил), поэтому я не понимаю, почему это не должно работать. – Matt

+0

@Matt это не сработает из-за различий в переменных среды ('env -i'). Что касается журналов, они обычно находятся в/var/log/syslog или другом '/ var/log/*'. Сделайте 'find/var -mmin -60 -print', чтобы увидеть, какие файлы изменились в последнее время. – VonC

+0

Я не уверен, что проблема с принудительной командой здесь, похоже, что ключ не принимается в случае, когда он является сервисом. См. Мое обновление. – Matt

Смежные вопросы