In this case, using openssh over putty was key.
Original answer (tips for debugging)
I can log in via ssh with the
gituser.
That means this works:
ssh git@serverIp
You do have a HOME variable defined, and ssh public/private keys (id_rsa / id_rsa.pub) in %HOME%/.ssh/.
This question suggests a different url:
git remote set-url test git@serverIp:/home/git/test.git
Make sure you did create your git repo as git (and not as root, when you created the git account, as in this question).
ssh git@serverIp "which git" should return the path of the git executable.
Check also that all parent directories have the relevant x (execute) bit set for the user git or the group gitgroup, running ls -ld /home /home/git /home/git/test.git.
Also, getting more info for a git command can be done with:
git push --verbose
or:GIT_TRACE=2 git push test master
If you have a private ssh key with a password, it would be best to first test those ssh commands with a private ssh key not password-protected, to see if the issue persists.
Or, you can keep that password-protected ssh key, but double-check your .bashrc as in this answer.
For any ssh connection issue (where git’s password is needed), check:
/var/log/auth.log,- an sshd debug session
In your case, since it works with ssh git@serverIp (interactive secure shell), but not with git (which opens a non-interactive secure shell), have a look at this thread, which references this one:
When ssh is started with a commandline, a non-interactive non-login shell is started.
However…bashdoes not use$BASH_ENVin this case, so setting it in~/.ssh/environment(e.g. to/etc/profile) doesn’t help.
What bash does is source/etc/bashrcand~/.bashrc.
Make sure that /etc/profile does define the path for git, since a non-login account could be used here (that seems to be the case here, since ssh git@serverIp "which git" worked, and ssh git@serverIp "git --version" should too).
But check also the right issue, and test a chmod 755 on /home, /home/git and /home/git/test.git.