CODEWITHSUNDEEP
sshgitolite
Matt
Matt

Reputation: 5567

gitolite not working with sshd service

I'm trying to get gitolite to work and have been stuck for hours. CentOS 6 server on my LAN.

I finally got ssh -vvv gitolite to work with this config file

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

BUT it only works when I do this on the server to debug

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

When sshd is running as a service, the connection fails.

http://pastebin.com/UHVS1sSK

Why does it work when I manually run sshd, but not with sshd as a service? It seems to use the same sshd_config file, because it uses the same port number. Also, my username gitolite is in the AllowUsers part of the config.

The success case looks like this:

http://pastebin.com/x4TcrG4R

Update: Here are the server-side logs

fail as a service: http://pastebin.com/Xce2k2x5

success: http://pastebin.com/jYgiDhEm

highlights from the fail case are below. Shouldn't the "key_from_blob" be the same in both cases? I've tried removing the command part of the authorized_keys and it still fails as a service.

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

highlights from the success case:

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

Upvotes: 1

Views: 621

Answers (1)

VonC
VonC

Reputation: 1323135

I suspect the keys are working in both cases.

But running sshd as a service is different than running it from the current session: see "Why would I use “service sshd reload” in preference to “service sshd restart”?".

The service cancels all inherited environment variables, and keep only PATH and TERM.

Gitolite uses a forced command registered in ~gitolite/.ssh/authorized_keys, and there must be an environment variable missing (when sshd is run as a service) which prevents the execution of the command.

There was a similar case with "public key authentication fails ONLY when sshd is daemon":

SELinux is likely the cause.
The .ssh dir is probably mislabeled.

Look at /var/log/audit/audit.log. It should be labeled ssh_home_t.
Check with ls -laZ. Run restorecon -r -vv /root/.ssh if need be.

Upvotes: 1

Related Questions