In this case, using openssh over putty was key.
Original answer (tips for debugging)
I can log in via ssh with the
git
user.
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…bash
does not use$BASH_ENV
in this case, so setting it in~/.ssh/environment
(e.g. to/etc/profile
) doesn’t help.
What bash does is source/etc/bashrc
and~/.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
.