Connecting to gitosis server through an SSH tunnel

Question

I've got an SSH tunnel setup on my macbook, like this...

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

So I can ssh to localhost:22222 and will end up on the gitosis-server behind the firewall.

I've created a local id_rsa.pub file, copied it into the gitosis server(running Centos5), and imported it into gitosis using...

# sudo -H -u gitosis gitosis-init 

It was successful as I can see the public key in /var/lib/gitosis/.ssh/authorized_keys.



Back on my macbook I setup a ~/.ssh/config file with the following...

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


So...I'm thinking this command should work...

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

It does not however as it comes up asking for a password....when the public keys should be working.

Initialized empty Git repository in /Users/USER/Development/gitrepo/gitosis-admin/.git/
gitosis@localhost's password: 


Any ideas on getting git working through to a gitosis server behind a firewall?

Thanks,

Matt



EDIT - Adding Debug From SSH Attempt

I did this command, 'ssh -vvv gitosis@gitosis-server'.  I get some debugging back and it doesn't seem to like my Identity.

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
gitosis@localhost's password: 



EDIT 2

OK...Definately a bad key.  I double checked all my keys again and of course found the gitosis-server was holding a bad key in the authorized_keys file.


debug1: userauth-request for user gitosis service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for "gitosis"
debug1: PAM: setting PAM_RHOST to "firewall.domain.com"
debug1: PAM: setting PAM_TTY to "ssh"
debug1: userauth-request for user gitosis service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 102/103 (e=0/0)
debug1: trying public key file /var/lib/gitosis/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 102/103 (e=0/0)
debug1: trying public key file /var/lib/gitosis/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for gitosis from FIRE.WALL.IP.ADDRESS port 52453 ssh2

I took a closer look at the authorized_keys file on the gitosis server....and it was incorrect. I double checked the public key file I had copied into /tmp from my workstation and it was the correct one, but different from what was in authorized_keys. I deleted the authorized_keys file on the server and reran the 'sudo -H -u gitosis gitosis-init < /tmp/id_rsa.gitosis.pub'. Checked the authorized_keys file again.....and it was still wrong.

I updated it manually by editing authorized_keys and adding the correct key, and then I got it to work from my workstation through the tunnel for one or two tries. Then it stopped working as before. I went back in to the authorized_keys file on the gitosis server, and sure enough....gitosis had reverted it back to the old key that does not work.

Why is it doing this....reverting back to a bad public key....even after I tried adding it with the above command...which failed to change it....then changed it manually....which worked but git then reverted back to the bad one again.

It's like gitosis keeps remembering the first key I put in there....and won't let me change it to the corrected key.

Frustrating...

Matt

Exogenous

Answer 1

Followup:

I'm not sure why gitosis insisted on reusing a bad public key. Trying to force it to take the correct key did not work.

So today I just removed and reinstalled the gitosis package on my CentOS5 box.

yum remove gitosis
rm -rf /var/lib/gitosis
yum install gitosis
sudo -H -u gitosis gitosis-init < /tmp/id_rsa.gitosis.pub  #the correct key

On my Mac, I SSH tunnel localhost:22222 through the firewall to gitosis-server:22.

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

On my Mac, I created ~/.ssh/config that looks like this...

Host gitosis-server
Hostname localhost
IdentityFile ~/.ssh/id_rsa.gitosis
HostKeyAlias gitosis-server.domain.com
  Port 22222

Then...following the instructions on this site...

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

...everything after... "Here some cool magic happens. Run this on your local machine:"... just works... except remember to replace the username "git" with "gitosis".

Hope all that nonsense helps somebody. Thanks also for the suggestions I got here....it helped narrow down the problem.

Matt

Exogenous

Answer 2

This is an ssh issue and not (yet) a git issue.

ssh -v is your friend as it will give you debug information about what authentication methods and keys ssh is attempting to use.

Nine times out of ten I find that this is an issue with permissions on key files. ssh likes your .ssh directory and your id_rsa file to be only writeable by 'user' and my umask allows group writeable files by default. ssh -v will tell you if this is the case in your situation.

Edit

It does look like the sshd server doesn't accept your identity. I don't know if you have access to the remote server, but running an sshd server in debug mode might help.

Running something like this allows one connection on the given port (so that it doesn't interrupt the normal sshd service) and outputs debug information. This may help debug why the server doesn't like your identity.

sshd -d -p 2022

If your 'normal' sshd service runs with extra parameters make sure to supply these to the debug version as well.

Trug

Hi Charles...thanks or the info. I debugged it on the server and figured out what was wrong....but still haven't solved the problem. See my edit in the original question. Thanks, Matt – Exogenous

Answer 3

My setup for similar situation (working)

I have similar setup for repo.or.cz (which is for some reason null-route blocked by ISP I use, Polish ISP Telekomunikacja S.A. (tpnet)), and it works for me:

I run the following command run to set up SSH tunel before attempting to connect:

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

(I use autossh instead of ssh to reconnect if I am disconnected, i.e. to keep connection up). Check that appropriate identities are added to SSH authentication agent:

$ 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)

I use keychain to have to provide passwords for my private SSH keys only once, at login.

I have the following set up in my ~/.ssh/config:

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

This setup works for me without problems.

---

Debugging your situation

As for debugging your situation?

First, I would check if I can log in to gateway using "ssh [email protected]", to check if SSH tunnel can be set up. If you are on Linux you can use for example netstat --tcp to check if there is connection established to gateway; on other operating systems and environments you can find similar utilities.

Check if you can connect correctly to gitosis. (If I remember correctly gitorious is using gitosis for managing access via SSH, so I used response from gitorious in example below)

$ ssh gitosis@gitosis-server
Need SSH_ORIGINAL_COMMAND
                             Connection to  closed.

If it doesn't do something similar to above (repo.or.cz returns "fatal: What do you think I am? A shell?", GitHub returns "Hi user! You've successfully authenticated, but GitHub does not provide shell access."), check where it fails with "ssh -v gitosis@gitosis-server":

$ ssh -v gitosis@gitosis-server
[...]
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)

Gereld

Charles/Jakob.... I did find that the id_rsa.gitosis and id_rsa.gitosis.pub identities were 644....I made them 700. Didn't seem to make a difference though. I'm pasting some of the debug into the original question. – Exogenous

Answer 4

You say you can ssh to localhost:2222 successfully. To check that you have set up ~/.ssh/config correctly, can you ssh to just gitosis-server?

ssh gitosis-server

Segment

If I 'ssh gitosis-server', it connects as my current user account (which also exists on the gitosis-server). So when I give it my password it logs in fine. – Exogenous

Answer 5

I had a similiar problem and I solved it with:

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

Maybe your keys were cached there?

Fred