3

I tried to install git on godaddy shared host following steps written in this tutorial. Git works, I created a commit and a copy, but I didn't manage to solve the path problem mentioned in step 5, so I cannot upload and download from remote computer. I found here a lot of questions in the same topic, tried everything, but haven't worked. Any idea how to fix it?

git error message:

bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

~/.gitconfig (created by "git config --global" commands)

[remote "origin"]
        receivepack = libexec/git-core/git-receive-pack
        uploadpack = libexec/git-core/git-upload-pack

~/.bash_profile

PS1="[\u@\h:\W]> "
export EDITOR=vim
export PATH=$PATH:$HOME/bin:$HOME/libexec/git-core
export LD_LIBRARY_PATH=$HOME/lib
export GIT_EXEC_PATH=~/libexec/git-core
export GIT_TEMPLATE_DIR=~/share/git-core/templates

I hate this :-(

Edit:

ssh connection log:

Welcome to Git (version 1.7.7.1-preview20111027)


Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.

inf3rno@INF3RNO-PC ~
$ ssh -vvv user@mygodaddyhost.com
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug2: ssh_connect: needpriv 0
debug1: Connecting to mygodaddyhost.com [11.111.111.1] port 22.
debug1: Connection established.
debug1: identity file /c/Users/inf3rno/.ssh/identity type -1
debug3: Not a RSA1 key file /c/Users/inf3rno/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /c/Users/inf3rno/.ssh/id_rsa type 1
debug1: identity file /c/Users/inf3rno/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1
debug1: match: OpenSSH_5.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g
roup-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@open
ssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-g
roup-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour1
28,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-c
tr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 139/256
debug2: bits set: 537/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /c/Users/inf3rno/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug3: check_host_in_hostfile: filename /c/Users/inf3rno/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 2
debug1: Host 'mygodaddyhost.com' is known and matches the DSA host key.
debug1: Found key in /c/Users/inf3rno/.ssh/known_hosts:2
debug2: bits set: 533/1024
debug1: ssh_dss_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /c/Users/inf3rno/.ssh/identity (0x0)
debug2: key: /c/Users/inf3rno/.ssh/id_rsa (0xa01a438)
debug2: key: /c/Users/inf3rno/.ssh/id_dsa (0x0)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password,ke
yboard-interactive
debug3: start over, passed a different list publickey,gssapi-with-mic,password,k
eyboard-interactive
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: Trying private key: /c/Users/inf3rno/.ssh/identity
debug3: no such identity: /c/Users/inf3rno/.ssh/identity
debug1: Offering public key: /c/Users/inf3rno/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff

debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 8
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 0
debug3: tty_make_modes: 7 0
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 0
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 0
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 0
debug3: tty_make_modes: 55 0
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 0
debug3: tty_make_modes: 61 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
Last login: Fri Apr 27 02:00:43 2012 from catv-111-11-111-11.catv.broadband.hu
[user@blabla:~]>

I can create, remove, download files via ssh, so I think the problem is with git, not with the ssh neither with my local computer settings.

Edit2: With git bash this worked:

git clone -u libexec/git-core/git-upload-pack user@host.com:myrepo.git "D:/myrepo"

So there is a git config problem I cannot solve, I tried to configure git this way:

git config --global remote.origin.receivepack libexec/git-core/git-receive-pack
git config --global remote.origin.uploadpack libexec/git-core/git-upload-pack

It was ineffective. In the tutorial there was no --global, but without that it gave me error: could not lock .git/config no such file or directory...

So the git works, but it has configuration problem, and there is another issue with git gui ssh connection...

ls -l .ssh
total 12
-rw------- 1 myuser inetuser  802 Apr 27 02:05 authorized_keys
-rw------- 1 myuser inetuser 1675 Apr 27 00:29 id_rsa
-rw------- 1 myuser inetuser  401 Apr 27 00:29 id_rsa.pub

Here are the file contents (ofc there are serious changes in every key)

vi authorized_keys
ssh-rsa CACAB3NzaC1yc2ECACAFiwCAAQEAugaPHL6tF9eKRNDVBTiIbV6tG6Nusl30EPjVT6z1fDLe2g0iXBFlcB+gziDYrJdLhpV78qShE8+uCM0e2RTSBbYEM3tiZprJy142ESPTLR3IkVEEpEH2hsGMHpP3n3rwSb9dExx/OozrkWYBPIa08TZmp27YE+DgF7ZrVF/WqL9MCnNUM8hllmmBRIuR/gTZHmvE3E5pmIgV7k7umR2xbXk6zsFqUrY7iSPIZSTxE/M26CzngnGaLjTLBlq091tEXxWWek6A9oTPKYCb0LXExKvP7z+hD/uEvdpMjwHI0rtjo600Xe+rYl+bSgl21BAv4y0QlI7gkFwpuuymwYq5aw== inf3rno@INF3RNO-PC

ssh-rsa CACAB3NzaC1yc2ECACAFiwCAAQEA2zjE1e5FT6cgBzNY3Stqc9eY4djVYg3EO/6YkCBUJ/Vxf3X/aXiVpyDmPBuTfWIimS4prtVoXA23bQ6WwdrtgiKPLKIohyV7MFJAOSlACzXlZe5QjzZx4WbLiyGxY32ImFfO1Px9EU71+AtSxXcPLaY1Yn9U/yRpZCU4Bp4E4+ZvrP8hGZwzWNcVBr/u3SsDhIJueqZWxDNvaHlN03P/56z9J4dCt/siPFbUvhu9ztmRamMBYiY72UgUhET7NIJfTZU+CqvIym4jBUKZ5h6ryWRRMYuDTZarSb/K+w0PxNw/eUX565K3MpE/qCAxC+1S3iVdMk6qoRy4tSapCdCtrQ== info@myhost.com
"authorized_keys" 3L, 802C                                    3,1           All


vi id_rsa.pub
ssh-rsa CACAB3NzaC1yc2ECACAFiwCAAQEA2zjE1e5FT6cgBzNY3Stqc9eY4djVYg3EO/6YkCBUJ/Vxf3X/aXiVpyDmPBuTfWIimS4prtVoXA23bQ6WwdrtgiKPLKIohyV7MFJAOSlACzXlZe5QjzZx4WbLiyGxY32ImFfO1Px9EU71+AtSxXcPLaY1Yn9U/yRpZCU4Bp4E4+ZvrP8hGZwzWNcVBr/u3SsDhIJueqZWxDNvaHlN03P/56z9J4dCt/siPFbUvhu9ztmRamMBYiY72UgUhET7NIJfTZU+CqvIym4jBUKZ5h6ryWRRMYuDTZarSb/K+w0PxNw/eUX565K3MpE/qCAxC+1S3iVdMk6qoRy4tSapCdCtrQ== info@myhost.com
"id_rsa.pub" 1L, 401C                                         1,1           All


vi id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBCAKCAQEA2zjE1e5FT6cgBzNY3Stqc9eY4djVYg3EO/6YkCBUJ/Vxf3X/
aXiVpyDmPBuTfWIimS4prtVoXA23bQ6WwdrtgiKPLKIohyV7MFJAOSlACzXlZe5Q
jzZx4WbLiyGxY32ImFfO1Px9EU71+AtSxXcPLaY1Yn9U/yRpZCU4Bp4E4+ZvrP8h
GZwzWNcVBr/u3SsDhIJueqZWxDNvaHlN03P/56z9J4dCt/siPFbUvhu9ztmRamMB
YiY72UgUhET7NIJfTZU+CqvIym4jBUKZ5h6ryWRRMYuDTZarSb/K+w0PxNw/eUX5
65K3MpE/qCAxC+1S3iVdMk6qoRy4tSapCdCtrQIFiwKCAQAZgR1af9S4pWK+/o3Q
IjgNPTYsarlNCOM6DnfV9RDun7UzI22lp2GLVWWR1lHFL8lwl44D5WWpmyrn5GkA
NkcHj1EprCHjj0FGzdt0PzqE8Dd5iQk08EeHeXZZCyo3QYv0J0rWg0F+Uiq9Qx9n
BkrgpUft/+x07gn6EuHU3tv8yaqrnD3ly6m8/tEA2NvsXWWsrR+u2gdXYqoS7z2e
OvaHELGywPvxPJ/q3udumqKes06+RbZX7ph1fzwYlDzy5pZ3qy4m7sMEISWY1SqL
VWhP1avv688mF03wlzoIFi7ORXDlRM9VLYHosMXgt85Zo2Q/f3MEi6hk+bQmEvHc
ZqkbAoGBAQgwoDFkdzMjrZj3XsRVPLGz0HBdxYoWmjKbdKPAY5MDZ02QYXuTqW07
jy4hT/w1kUxyz4kp17MC9lp2ItnjEOUjXFIKFqRFf7dxtcxKodM6MbI8YlPk0f9h
Xv7v97NnLhXG1RPbON9RllC4q4gTg+1RoSPQHxtsJghYqxDVBUIbAoGBAOIex9Ia
bvUKc9dHe5Yzx2qGxyji7E9w+eynVnEqjH/Gc5y7DSqlfz25qT2VArILh1cFWXy2
5tLSOGm2EQwED9Wivxgr6/oczGKZ45lYUAfDnP6B2drrGMHvNZBE7XrQzo3cVs/n
C6cn8CuBLGHIE7hg6QrgqQ/BbcgPVdPsSSGvAoGAf6P6nQ8Yvdny4PQ/Xagt182P
xMKC2Uz134MmfR11Ccc8cQhspfQrP323WY15l6aFO6/Z0YM7uyYYTRFiYW12ZzbB
w8qsjv8rvW2t9AkgBjsvgDxP01+8dLW705Fa0UsBwg58Nhj4rV0ou8yv+Y+FrT/s
eNFvFWrRuyZJWR0YpacCgYEArm+ENF2Iy6j6Rv0A30yD5HaZozK2S+lwV3nGV0y1
hyQQCzE2CvSynVS1wcq477/ARpADNFKUzoTpsKJk7AMiKHY7pO6uuaEv9ErUJdZp
n6QKQK1QSctNnOu7my3bxSS8mVI0Vz004Ajd2Gr2Wg9fq331mq1POAo+vudCNcTn
"id_rsa" 27L, 1675C                                           2,1
fedorqui
  • 275,237
  • 103
  • 548
  • 598
inf3rno
  • 24,976
  • 11
  • 115
  • 197
  • Your private key is strange, and should end with a "`-----END RSA PRIVATE KEY-----`", a bit like in http://forums.vandyke.com/showthread.php?t=2185. Maybe you have truncated that key intentionally? – VonC Apr 27 '12 at 22:41
  • nope, that's it, I just changed characters for example AA -> Ep, etc... – inf3rno Apr 28 '12 at 06:06
  • In that case, I am not convinced the content of that private key is a valid one. – VonC Apr 28 '12 at 06:44
  • Ok I try to generate a new one. – inf3rno Apr 28 '12 at 16:42
  • Generated new keys, now the gui is working too, it sends the same error message: git-upload-pack: command not found... – inf3rno Apr 28 '12 at 16:50
  • I found, that the "git config remote.origin.receivepack path" works only in a repo, and creates config for the repo ... So with the --global flag should be good too... I gave the absolute path returned by "pwd", but it's not effective. :S I hate that it prints that cannot find command, but never displays where it had been looking for that... – inf3rno Apr 28 '12 at 17:05
  • Maybe the problem is with the "origin" naming. By first pull the repo called "origin" doesn't exist.. – inf3rno Apr 28 '12 at 17:20
  • I found that git clone names the repo automatically "origin", so the naming can't be a problem. – inf3rno Apr 28 '12 at 17:42
  • Sorry for the delay: I was in a train, back from SOMeetup Paris (https://twitter.com/#!/VonC_/status/196252656493264897 and http://www.meetup.com/stackoverflow/Paris-FR/655032/?a=bn5_l1#1233402). So the ssh keys are working better now, right? Only remains the issue to the uploadpack path. – VonC Apr 28 '12 at 18:25
  • Yepp :-) The ssh working now, the git config remained. – inf3rno Apr 28 '12 at 18:44
  • I have added your (initially rejected) edit in my answer below. – VonC Jul 18 '13 at 14:31

1 Answers1

2

I would try with the full path for those executable:

[remote "origin"]
        receivepack = /full/absolute/path/to/libexec/git-core/git-receive-pack
        uploadpack = /full/absolute/path/to/libexec/git-core/git-upload-pack

I confirm that is your system sshd_config contains PermitUserEnvironment no, your .bashrc is not relevant in an SSH session.

The OP inf3rno concludes:

Ok. There was a misunderstanding by git clone.
The local machine config file must have the location of the upload pack not the config file on the server.
Another solution could be, that before the clone we insert a config file on the server which contains the location of git binaries.
I tried the first solution, it works well.

Note:

debug1: identity file /c/Users/inf3rno/.ssh/identity type -1
debug3: Not a RSA1 key file /c/Users/inf3rno/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace

is a tell-tale of a public SSH key not copied properly (either at the source in /c/Users/inf3rno/.ssh/id_rsa, or at the destination, in ~/.ssh/authorized_keys).
It usually means that the key has been spit in several lines, instead of being one long line (mentioned in this answer.

So something like:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAybmcqaU/Xos/GhYCzkV+kDsK8+A5OjaK
5WgLMqmu38aPo56Od10RQ3EiB42DjRVY8trXS1NH4jbURQPERr2LHCCYq6tHJYfJNhUX
/COwHs+ozNPE83CYDhK4AhabahnltFE5ZbefwXW4FoKOO+n8AdDfSXOazpPas8jXi5bE
wNf7heZT++a/Qxbu9JHF1huThuDuxOtIWl07G+tKqzggFVknM5CoJCFxaik91lNGgu2O
TKfY94c/ieETOXE5L+fVrbtOh7DTFMjIYAWNxy4tlMR/59UVw5dapAxH9J2lZglkj0w0
LwFI+7hZu9XvNfMKMKg+ERAz9XHYH3608RL1RQ== This comment describes the 
key

instead of:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAybmcqaU/Xos/GhYCzkV+kDsK8+A5OjaK5WgLMqmu38aPo56Od10RQ3EiB42DjRVY8trXS1NH4jbURQPERr2LHCCYq6tHJYfJNhUX/COwHs+ozNPE83CYDhK4AhabahnltFE5ZbefwXW4FoKOO+n8AdDfSXOazpPas8jXi5bEwNf7heZT++a/Qxbu9JHF1huThuDuxOtIWl07G+tKqzggFVknM5CoJCFxaik91lNGgu2OTKfY94c/ieETOXE5L+fVrbtOh7DTFMjIYAWNxy4tlMR/59UVw5dapAxH9J2lZglkj0w0LwFI+7hZu9XvNfMKMKg+ERAz9XHYH3608RL1RQ== This comment describes the key

The OP Inf3rno mentions:

Server side solution for the config problem [edited by inf3rno]:

I installed the git to the ~/git and added the following files:

~/.ssh/authorized_keys:

command="~/connect.sh" ssh-rsa aaaaaaaaaaaaa... == inf3rno@INF3RNO-PC

~/connect.sh:

#!/bin/bash
if [ -f "${HOME}/.env_profile" ]; then
        source ~/.env_profile
fi;

if [ "x${SSH_ORIGINAL_COMMAND}x" == "xx" ]; then
        $SHELL --login
else
        eval "${SSH_ORIGINAL_COMMAND}"
fi;

~/.env_profile:

    export PATH=$PATH:$HOME/bin:$HOME/git/libexec/git-core
    export LD_LIBRARY_PATH=$HOME/git/lib
    export GIT_EXEC_PATH=~/git/libexec/git-core
    export GIT_TEMPLATE_DIR=~/git/share/git-core/templates

So now it sets the env variables before any git command...
Sadly there is no other way by GoDaddy, just the authorized_keys hax. Another files are not executed before the git commands.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Strange, I already tried with the absolute path (asked with pwd), but now it works: I got a new error message: wrong pasword XD That's funny cause I already copied my public key to ~/.ssh/authorized_keys ... – inf3rno Apr 27 '12 at 07:41
  • @inf3rno that is completely different. For debugging an ssh connection, please see http://stackoverflow.com/questions/6018551/heroku-push-master-ssh-problem/6018945#6018945 and mainly: http://stackoverflow.com/questions/922210/unable-to-git-push-master-to-github/922461#922461 – VonC Apr 27 '12 at 07:52
  • Yeah but I can connect from git bash without password (so with my public key), just the copy repo not works. I'll try from bash maybe... – inf3rno Apr 27 '12 at 08:04
  • Ok from git gui I get (requires password who knows why): "Permission denied (publickey,gssapi-with-mic,password,keyboard-interactive). fatal: The remote end hung up unexpectedly" From git bash I get: "$ git clone user@host.com:myrepo.git "D:/path/to/myrepo" Cloning into D:/path/to/myrepo... bash: git-upload-pack: command not found fatal: The remote end hung up unexpectedly" Is that a joke? They shouldn't be different! – inf3rno Apr 27 '12 at 08:31
  • @inf3rno: "`git gui` requires password": that means it didn't found your public/private key (probably because `HOME` isn't define in Windows). git bash (which defines `HOME` before launching the bash session, which explains the difference): it finds the keys, so no password here, but there is still an issue with `uploadpack`... – VonC Apr 27 '12 at 08:35
  • Ye I got the absolute path from output of pwd, but it's not working :S – inf3rno Apr 27 '12 at 08:38
  • Hmm if the gui doesn't find the public key, how is that possible that I already used it several times to push projects to github? :D – inf3rno Apr 27 '12 at 08:41
  • @inf3rno pushing to GitHub with the same public / private key (than the one you are using for pushing to your new repo on GoDaddy)? – VonC Apr 27 '12 at 08:44
  • Ofc :D I can be sure that the problem is on the server not on localhost cause it works by github.... – inf3rno Apr 27 '12 at 08:46
  • @inf3rno Very possible: make sure the key is registered, and that the rights for .ssh on the server are correct (as seen here http://stackoverflow.com/questions/8363903/ssh-key-on-dreamhost or here http://stackoverflow.com/questions/4616358/ssh-giving-me-a-permission-denied) – VonC Apr 27 '12 at 08:54
  • Ok I added git bash ssh debug to the question, but I think nothing relevant is there... – inf3rno Apr 27 '12 at 09:21
  • @inf3rno oh that's a classic: the local user public key is copied on several lines instead of one (result of a copy/paste) in the `~/.ssh/authorized_keys` file => put it on one line – VonC Apr 27 '12 at 09:37
  • I have 2 public keys on that file: the first is my home public key after that are two line breaks and after that comes the server public key. So it's not in 2 lines... Does the gap count between them? – inf3rno Apr 27 '12 at 17:44
  • @inf3rno no, as long as each keys are in one line each, you should be ok. Is this the case for for the source files (public keys) and the destination file (as mentioned in my edited answer above)? – VonC Apr 27 '12 at 17:48
  • Tthe id_rsa.pub is in one line the id_rsa (so the private key) is in multiple lines. (They are generated by git.) – inf3rno Apr 27 '12 at 17:53
  • @inf3rno yes, private key files are on multiple line. But somehow, the content of `id_rsa` must not be fully valid... – VonC Apr 27 '12 at 18:00
  • As I said it was generated by git, I haven't modified that file since ssh keygen. Is that possible that the ssh keygen went wrong but the files were created? – inf3rno Apr 27 '12 at 18:04
  • The really strange is that git gui asking for ssh password, but if I give it the password of the actual user it does not accept it... (I already connected successfully with that password via putty, so I think it's deeper than a simple ssh problem.) – inf3rno Apr 27 '12 at 18:18
  • @inf3rno yes, git gui asking for a password simply means it doesn't find or interpret correctly your ssh keys, which means it falls back to the only authentication mechanism left: plain password. – VonC Apr 27 '12 at 18:20
  • ok, but the user is the same than in putty ssh, and the password is the same, so why doesn't grant it access after giving the proper password? Is there any log of git gui? – inf3rno Apr 27 '12 at 18:23
  • I generated the keys with this: ssh-keygen -t rsa -b 2048 -C "info@myhost.com" Is there a problem with that? – inf3rno Apr 27 '12 at 18:30
  • @inf3rno looks good for the `ssh-keygen`. Try define `HOME` first, before launching `git-gui` (unless you are launching it from the `git bash`, in which case `HOME` is defined, and we are back to the `id_rsa` somehow invalid content step). – VonC Apr 27 '12 at 19:05
  • @inf3rno wait a minute... "`debug1: Offering public key: /c/Users/inf3rno/.ssh/id_rsa`"? That reminds me of http://stackoverflow.com/questions/2696487/ssh-permission-denied Not sure it is related, just mentioning it in case it is. – VonC Apr 27 '12 at 19:50
  • What's you point? Should I try to move that keys on my local computer? Hmm btw how can I configure the git gui home? I thought the gui uses same config than the bash... – inf3rno Apr 27 '12 at 20:31
  • @inf3rno no, I was just looking for anything related to your case. If the source seems good, I would check the destination (`~/.ssh/authorized_keys`, with their rights and content) – VonC Apr 27 '12 at 21:29
  • What's the importance of "PermitUserEnvironment no"? I found the sshd_config, but it doesn't contain it. – inf3rno Apr 28 '12 at 16:51
  • Ok. There was a misunderstanding by git clone. The local machine config file must have the location of the upload pack not the config file on the server. Another solution could be, that before the clone we insert a config file on the server which contains the location of git binaries. I tried the first solution, it works well. I have problems with understanding bare and non bare repos, but that will be another question. Thanks for the help! – inf3rno May 13 '12 at 10:49
  • @inf3rno ok I have included your conclusion in the answer for more visibility – VonC May 13 '12 at 11:48