3
  1. I have installed Gitlab in /home/myuser/gitlab.
    1. I created a rep test
    2. Following instructions, I added a remote git@localhost:root/testing.git

I found that there was a problem with my ssh connect. Here's my /home/myhome/.ssh/config file 

Host mylocalhost
Hostname localhost
User git
IdentityFile /home/myuser/.ssh/id_rsa

When I run git push -u origin master I am asked to enter my passphrase. But, immediately after I get this message 

Connection closed by ::1

fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Where am I going wrong ? Is this my ssh connection

Update : I stopped sshd and the ran sshd -d (in my /home/myhome) and then ssh -T mylocalhost, I got in the ssh -d output

debug1: sshd version OpenSSH_6.2, OSSLShim 0.9.8r 8 Dec 2011
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: fd 6 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 6 out 6 newsock 6 pipe -1 sock 9
debug1: inetd sockets after dupping: 5, 5
Connection from ::1 port 51579
debug1: Client protocol version 2.0; client software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: permanently_set_uid: 75/75 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none [preauth]
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user git service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "git"
debug1: PAM: setting PAM_RHOST to "localhost"
debug1: userauth-request for user git service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: test whether pkalg/pkblob are acceptable [preauth]
debug1: temporarily_use_uid: 1111/20 (e=0/0)
debug1: trying public key file /Users/git/.ssh/authorized_keys
debug1: fd 6 clearing O_NONBLOCK
debug1: matching key found: file /Users/git/.ssh/authorized_keys, line 1
Found matching RSA key: e9:70:a8:96:1c:a5:b4:b0:58:b0:b8:22:6f:9b:98:bb
debug1: restore_uid: 0/0
Postponed publickey for git from ::1 port 51579 ssh2 [preauth]
debug1: userauth-request for user git service ssh-connection method publickey [preauth]
debug1: attempt 2 failures 0 [preauth]
debug1: temporarily_use_uid: 1111/20 (e=0/0)
debug1: trying public key file /Users/git/.ssh/authorized_keys
debug1: fd 6 clearing O_NONBLOCK
debug1: matching key found: file /Users/git/.ssh/authorized_keys, line 1
Found matching RSA key: e9:70:a8:96:1c:a5:b4:b0:58:b0:b8:22:6f:9b:98:bb
debug1: restore_uid: 0/0
debug1: ssh_rsa_verify: signature correct
debug1: do_pam_account: called
Failed publickey for git from ::1 port 51579 ssh2
debug1: audit_event: unhandled event 6
Access denied for user git by PAM account configuration [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: PAM: cleanup
debug1: Killing privsep child 17748
debug1: audit_event: unhandled event 12

Btw, each time I run some git command, I get the message 

ssh: Could not resolve hostname mylocalhost: nodename nor servname provided, or not known
fatal: Could not read from remote repository.

Update 2

When I run ssh mylocalhost, I have the good message Welcome to GitLab, Administrator!. But then, I get the following input 

debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 0: rcvd close
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

Transferred: sent 3284, received 3480 bytes, in 0.4 seconds
Bytes per second: sent 7501.3, received 7949.0
debug1: Exit status 0`

and in my GitLab log 

Started GET "/api/v3/internal/allowed?key_id=4&action=git-receive-pack&ref=_any&project=testing" for 127.0.0.1 at 2013-11-07 16:48:00 +0100
epsilones
  • 11,279
  • 21
  • 61
  • 85

1 Answers1

3

If you are using the SCP-like syntax for the ssh url, then, considering your ~/.ssh/config, that url should be:

git remote set-url origin mylocalhost:root/testing.git

That supposes that you have added your public key (the ~/.ssh/id_rsa.pub) in your GitLab account page:

https://intranet.5amsolutions.com/download/attachments/24610136/Git3.png?version=1&modificationDate=1349371375213

And that the access protection is correct

The OP Newben reports (in the comments):

I had to go to my osx shared preferences panel and set manually the users remote access perms.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • that's what I did, but it failed. In fact, if I run `ssh mylocalhost`, I am told to enter the passphrase. As soon as I enter it, I get this message : `debug1: key_parse_private_pem: PEM_read_PrivateKey failed debug1: read PEM private key done: type Enter passphrase for key '/home/myuser/.ssh/id_rsa': debug1: read PEM private key done: type RSA Connection closed by ::1` – epsilones Nov 05 '13 at 21:00
  • @Newben did you published your ssh key on the Gitlab side? (in one line) – VonC Nov 05 '13 at 21:01
  • Do you mean if I added the `ssh key` on the local site ? – epsilones Nov 05 '13 at 21:02
  • No: you have to copy the content of the public key in the keys section of your profile, in GitLab. – VonC Nov 05 '13 at 21:03
  • I went on Gitlab and I added the content of the key, and I was told it was already added. Btw, if I retrieve the following line from the `authorized_keys`, I get the same message `command="/Users/git/gitlab-shell/bin/gitlab-shell key-4",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa` – epsilones Nov 05 '13 at 21:09
  • My key was indeed correctly set on `GitLab`. Btw, I added the correct permissions as suggested. So, now when I try to ssh, I am not asked for a passphrase, but instead a password, (that I don't have) – epsilones Nov 05 '13 at 21:18
  • Should I delete the key in gitlab and in `/home/myuser/`, and install new ones, because I spent all day on the pb without any solution... – epsilones Nov 05 '13 at 22:00
  • @Newben you can do that (or even add a new one, and reference it in your `~/.ssh/config` file, meaning you don't have to delete the old one). Then you can try some ssh debug tips (http://stackoverflow.com/a/922461/6309) on the client side: `ssh -Tvvv`. And on the server side (http://stackoverflow.com/a/17774456/6309 or http://stackoverflow.com/a/12680114/6309), an `sshd -d` session. – VonC Nov 05 '13 at 22:12
  • I tried to install again a key, set the right perms, nothing to do... The weird thing is that with the new permes I am no longer asked for the passphrase, and when setting back to older perms (the one that allowed me to be asked for the passphrase), I am not asked the passphrase anymore. I am quite lost – epsilones Nov 05 '13 at 22:47
  • I established the perm of `.ssh` to 755, and now I am asked again the passphrase, which is good, but I still have this message `debug1: key_parse_private_pem: PEM_read_PrivateKey failed debug1: read PEM private key done: type Enter passphrase for key '/Users/git/.ssh/id_rsa': debug1: read PEM private key done: type RSA Connection closed by ::1` – epsilones Nov 05 '13 at 23:09
  • @Newben Could you try with a private key *not* passphrase protected, to see if that work? If you insist on keeping a passphrase protected provate key, then you need an ssh agent (that you need to launch as in http://stackoverflow.com/a/16118968/6309). – VonC Nov 06 '13 at 06:49
  • you mean by running `ssh-keygen -t rsa -p ''`, with an empty passphrase ? – epsilones Nov 06 '13 at 11:00
  • @Newben yes (as in http://stackoverflow.com/a/19022711/6309), otherwise you need an ssh-agent (http://stackoverflow.com/q/13516119/6309) – VonC Nov 06 '13 at 11:27
  • I did like you told. But now, I am asked forpassword... I don't understand anything... – epsilones Nov 06 '13 at 11:51
  • @Newben that simply means the public key isn't recognized correctly. Now you can double check everything, without having to deal with ssh-agent and passphrase: easier to debug. So: `ssh -Tvvv` on the client, and `sshd -d` on the server, like above. Those logs should give you some clue. Check the protections (client and server), and the` ~/.ssh/authorized_keys` (it must contain your public key) – VonC Nov 06 '13 at 11:53
  • hi again, now I set the perms and I am not asked any password. But the connection is still closing. Here are the last lines debug output `debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok: fp e9:70:a8:96:1c:a5:b4:b0:58:b0:b8:22:6f:9b:98:bb debug3: sign_and_send_pubkey: RSA e9:70:a8:96:1c:a5:b4:b0:58:b0:b8:22:6f:9b:98:bb debug1: read PEM private key done: type RSA Connection closed by ::1 ` – epsilones Nov 06 '13 at 12:11
  • btw, when running `sudo /usr/sbin/sshd -d`, I get `debug1: sshd version OpenSSH_6.2, OSSLShim 0.9.8r 8 Dec 2011 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 0.0.0.0. Bind to port 22 on 0.0.0.0 failed: Address already in use. debug1: Bind to port 22 on ::. Bind to port 22 on :: failed: Address already in use. Cannot bind any address. ` – epsilones Nov 06 '13 at 12:13
  • @Newben that could mean it is working as intended: an `ssh -T` should not print much anyway. Now you must have a gitlab logs. Check also if `git clone` is working and if the issue is limited to `git push`. – VonC Nov 06 '13 at 12:14
  • @Newben regarding `sshd -d`, you need to stop `sshd` first, then run `sshd -d`: it is a one time session. After analyzing the output, you will need to restart `sshd`. – VonC Nov 06 '13 at 12:15
  • So first, `sshd -d` outputs ` debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-d' debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Bind to port 22 on ::. Server listening on :: port 22.` When restart `sshd` and cloning some repo outputs `no such identity: /home/myhome/.ssh/id_dsa: No such file or directory` and the some password (that I don't know).... – epsilones Nov 06 '13 at 12:25
  • @Newben the idea behind running `sshd -d` on the server, is for you to run a `ssh -T` on the client side, in order to see how the `sshd` reacts on the server. But again, if no password is asked, ssh probably is working fine. That would just be a way to confirm it. The fact that git operations don't work would then be a gitlab issue (hence the gitlab logs). So: 1/ first confirm ssh works. 2/ Try git commands, and if they aren't working, check the gitlab logs. – VonC Nov 06 '13 at 12:28
  • I have edited my post in order to make it more readable for you – epsilones Nov 06 '13 at 12:46
  • @Newben did you used, on the client, an `ssh -T mylocalhost`? Is that command which returns `Could not resolve hostname mylocalhost`? Because then, it means your `~/.ssh/config` file is incorrect (client side). But since your `sshd` answered something, it means you must have tested it with another `ssh` command from the client. which was it? For an `sshd -d` to fail on a PAM error message, you should check your `/etc/shadow` file: http://serverfault.com/a/540008 – VonC Nov 06 '13 at 12:53
  • yes I used on the client `ssh -T mylocalhost` and that command outputed `ssh: connect to host localhost port 22: Connection refused` – epsilones Nov 06 '13 at 12:56
  • @Newben as mentioned here https://www.dalemacartney.com/2013/01/12/host-based-access-control-with-red-hat-enterprise-linux-6/, you can see more at `/var/log/secure`, regarding the PAM error. – VonC Nov 06 '13 at 12:57
  • @Newben ok, that means the `~/.ssh/config` is correctly interpreted. Time to check `/var/log/secure` and `/etc/shadow` regarding that PAM error returns by your `sshd -d` one-time session. – VonC Nov 06 '13 at 12:58
  • 1
    Ok I am in !!! I had to go to my osx shared preferences panel and set manually the users remote access perms. Thanks so much ! – epsilones Nov 06 '13 at 13:13
  • @Newben Great! I have included your conclusion in the answer for more visibility. – VonC Nov 06 '13 at 13:15
  • Sorry, I reopen the question. When I run `ssh mylocalhost`, I have the good message `Welcome to GitLab, Administrator!`, so the ssh connection is now establishing. But then, I get the input I have just edited – epsilones Nov 07 '13 at 15:49
  • @Newben reopen it in a new question, with a link back to this one. That will be clearer. – VonC Nov 07 '13 at 15:50