I am using stash as a git repository manager. stash enables you to add ssh keys for each user trying to connect and clone from it. I have configured it fine for all unix use
On the client side (Jenkins), you need to check if the user running the Jenkins Jobs knows about a %HOME%
environment variable: it needs its %HOME%.ssh\id_rsa.pub public ssh key there.
See "Jenkins - Git - Permission denied (publickey)"
On the server (Stash from Atlassian), you need to make sure the ~stachAadminAccount\.ssh\authorized_keys
does contain your public key.
Beside that, you need to debug the ssh connexion:
ssh -vvvT ssh://git@stash.atlassian.com:7999/path/to/repo.git
(replacing git
by the account used for administrating Stash, and replacing stash.atlassian.com:7999
by your server:port
)
1) I have explicitly added
%HOME%
to the system env vars on the slave , just to make sure it's injected in. it may not be needed but I added it to see if it will have an affect
It is needed: ssh will look for keys (private and public) under %HOME%/.ssh
2) I never had to mess with ssh keys under stash. in fact, all the users for stash are internal to stash and are not part of the
/etc/password
file or anything like that, so noauthorized_keys
file exists anyway – user1577236 7 hours ago
a/ " not part of the /etc/password
file": Sure those are not registered in /etc/password: we are not talking about user account here, but about ssh keys allowing a user to open a secure shell session as one unique user account (the stash admin account): all ssh commands will be executed under the same account.
b/ "no authorized_keys
file": of course it should exist: when you are reporting that a clone with ssh protocol works, it involves a pure ssh communication, which means looking for public key on the server side in a ~/.ssh/authorized_keys
.
The only way that file doesn't exist is if Stash launch its own ssh daemon, configured to look for keys in another file/source of public keys.
regarding 2 - what you do in stash is to add the public key into a spacial place in stash, for each user.
That may be, but Stash should just be a nice front-end for ssh. All the ssh mechanism behind it should still be updated.
3) as mentioned, running the git clone command from the command line with git ssh protocol works fine, so what should I be looking for in the debug session ?
You must define a Jenkins job which does the ssh -vvvT
as its sole command: that way, you would see what doesn't work from the Jenkins perspective.
I would love to debug the Jenkins process and to see what it does during it's ssh session, but I don't know how to do that ( yet...). just started to work with Jenkins 2 weeks ago or so.
On windows, a process explorer is at least one first step in order to see under which account, and with what environment variable the Jenkins process (and its jobs) are running.