6

I have a weird issue here. Our Maven release plugin fails because it can't push a tag to Git. The following fails:

git push ssh://PU0S:xL8q@git-eim.fg.com/u0r0-SS/workspace-proxy.git workspace-proxy-server-1.10.1
[ERROR] Permission denied (publickey).
[ERROR] fatal: Could not read from remote repository.
[ERROR] 
[ERROR] Please make sure you have the correct access rights
[ERROR] and the repository exists.

If I remote into the machine and try pushing with an URL of the form I get the same error:

git push ssh://PU0S:xL8q@git-eim.fg.com/u0r0-SS/workspace-proxy.git

If I just push using the defined remote, it succeeds:

git push origin master

The above makes me certain that the .ssh keys are available on the machine. Why does the first form fail?

timmy
  • 1,752
  • 6
  • 23
  • 35
  • So if you checked out workspace-proxy-server-1.10.1 on this remote, you will be able to push if your machine's public key is added to the settings of this repo, if the repo does not know your public key you won't be able to push (/root/.ssh/id_rsa.pub or /youruser/.ssh/id_rsa.pub content needs to be copied to the remote repo to grant access) – dmitryro Jun 30 '16 at 22:43
  • I wonder how much of a spike in requests to git-eim.fg.rbc.com we'll get from this question ;) – Populus Jun 30 '16 at 22:46
  • So I am trying a few more things. Any idea why the following command fails `git clone ssh://git-eim.fg.com/u0r0-SS/workspace-proxy.git` but the following succeeds `ssh://git@git-eim.fg.com/u0r0-SS/workspace-proxy.git`? What is special about git@? – timmy Jul 03 '16 at 03:12

3 Answers3

2

Any idea why the following command fails git clone ssh://git-eim.fg.com/u0r0-SS/workspace-proxy.git but the following succeeds ssh://git@git-eim.fg.com/u0r0-SS/workspace-proxy.git?
What is special about git@?

git@ means the user which will receive the push will be git. The authentication is then managed by the public key used for ssh.
This differs from PU0S:xL8q, which is a username/password, only required when using an https url.
For an ssh url, you never push "as you" (PU0S) but as the account managing the git repos on the server side.
That is why, for instance, you always push at git@github.com.

If git push origin master succeeds, that means the url associated to the remote named 'origin' is correctly formed.
Typically ssh://git@git-eim.fg.com/u0r0-SS/workspace-proxy.git.

Check with git remote -v, or, since git 2.7, with git remote get-url origin.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • It seems `git@` doesn't have to exist in the server. For instance, this command works for me: `git clone foo@git-eim.fg.com/u0r0-SS/workspace-proxy.git`. Does this surprise you? – timmy Jul 04 '16 at 11:22
  • @timmy it depends on the nature of the git server (is it managed by gitolite, gitlab, other?). But a clone could work for any account, as you give the full absolute path of the repo, bypassing any control that a git hosting service (like gitolite or gitlab) might have put in place with their special account git. – VonC Jul 04 '16 at 11:25
  • @timmy In short, if you have the full absolute path of a repo, git alone will not control authentication or authorization, as I explain in http://stackoverflow.com/a/5685757/6309 – VonC Jul 04 '16 at 11:26
  • @timmy if `/u0r0-SS/workspace-proxy.git` is create by `bar`, trying a push with `foo@git-eim.fg.com/u0r0-SS/workspace-proxy.git` should fail, as `foo` does not have write access to `bar` folders. – VonC Jul 04 '16 at 11:27
0

git looks for the ssh in a certain location under you .ssh folder.

Set the keys in the config file and you should be able to clone it.

Open a terminal window. Edit the ~/.ssh/config file.
If you don't have a config file, create one. Add an alias for each identity combination for example:

Host workid
HostName github.com 
IdentityFile ~/.ssh/workid
CodeWizard
  • 128,036
  • 21
  • 144
  • 167
  • So I am trying a few more things. Any idea why the following command fails `git clone ssh://git-eim.fg.com/u0r0-SS/workspace-proxy.git` but the following succeeds `ssh://git@git-eim.fg.com/u0r0-SS/workspace-proxy.git`? What is special about git@? – timmy Jul 03 '16 at 03:12
0

The following clues helped in diagnosing the problem.

First, lets try ssh -vT without specifying a user. Note that the session assumes that the user is the account that is logged on, which has special character ('SE121947+PVHF0ONE_SS')!

 $ ssh -vT git-eim.fg.com
OpenSSH_7.1p2, OpenSSL 1.0.2g  1 Mar 2016
....
debug1: Authenticating to git-eim.fg.com:22 as'SE121947+PVHF0ONE_SS'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /c/Users/PVHF0ONE_SS/.ssh/id_rsa
debug1: No more authentication methods to try.

Permission denied (publickey).

Now lets try it with specifying git@git-eim.fg.com

$ ssh -vT git@git-eim.fg.com
OpenSSH_7.1p2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to git-eim.fg.com [10.238.35.34] port 22.
debug1: Connection established.
debug1: identity file /c/Users/PVHF0ONE_SS/.ssh/id_rsa type 1
...
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
Authenticated to git-eim.fg.com ([10.238.35.34]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
Hi PU0R0SRVDEVOPS! You've successfully authenticated, but GitHub does not provide shell access.

Strange thing is git@ can be replaced by foo@ and the authentication works! It's almost like it is merely a placeholder. So the fix was making sure the developerConnection in the pom.xml had a git@ in order for git to be able to authenticated.

timmy
  • 1,752
  • 6
  • 23
  • 35
  • "Strange thing is `git@` can be replaced by `foo@` and the authentication works! It's almost like it is merely a placeholder." No, it is not a placeholder. If it works with `foo`, it means `~foo/.ssh/authorized_keys` has your ssh public key. My answer recommended the use of `git@` all along. – VonC Jul 12 '16 at 06:49
  • I tried this against github.com: `ssh -Tv crazy@github.com`. And it works. Trust me, I don't have a user called crazy. It did pick up the key in my ~/.ssh folder. Do you have any documentation of git@? I couldn't find any. – timmy Jul 13 '16 at 01:46
  • GitHub does not manage ssh keys as any normal ssh server would. It has its own public key management system. The user in front of @github does not matter. What matter is that your public key is registered to your GitHub account. – VonC Jul 13 '16 at 06:33
  • My answer still stands though, and is the correct one for a private server. – VonC Jul 13 '16 at 06:34
  • So a privately hosted GitHub, manages ssh keys differently than a publicly hosted GitHub? Maybe that is the confusion here. The original question is regarding a privately hosted GitHub instance. – timmy Jul 13 '16 at 13:26
  • Yes, a privately hosted GitHub deals with *far less* users than the public github.com. Did you test `ssh -Tv crazy@my-private-github.com`? – VonC Jul 13 '16 at 14:51
  • Yes, the output from my answer is from performing an `ssh -Tv foo@my-private-github.com` – timmy Jul 14 '16 at 01:38