'git push' over SSH does not close issues, but does over HTTP(S).

[pcopissa]

• Gitea version (or commit ref): 1.5.2
• Git version: 2.18
• Operating system: CentOS 7.5 (server) / Windows 10 (client)
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • [?] MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

0a) On on Centos 7.5 server, installed Gitea 1.5.2, git 2.18 (Followed steps at https://docs.gitea.io/en-us/install-from-binary/). Started Gitea web server as a service.
0b) On Windows 10 client, installed MSYS2 git 2.15 + Putty. Substituted ssh with Putty's PLINK.EXE by setting the GIT_SSH environment variable. Also start PAGEANT.EXE and insert the ppk file for Centos login git who is running gitea service.

1. Sign up first (administrative) account p.copissa via web UI, and setup the server with a few custom values (as shown in the Site administration > Configuration web page):

Gitea Base URL           http://git.lan:3000/
SSH Server Domain        git.lan
Repository Root Path     /var/lib/git
Static File Root Path    /var/lib/gitea
Log Path                 /var/lib/gitea/log

Also register a Gitea user named git with the same password as the Centos git login.

2. In the web UI, log in as p.copissa, create a repository test, (be sure to tick the check box Initialize Repository to avoid issue When creating repo without init it shows still howto #2898), create two issues (Rename import paths: "github.com/gogits/gogs" -> "github.com/go-gitea/gitea" #1 and Fix sender of issue notifications #2).

3. On the client, clone repository test via HTTP (or HTTPS) using git.exe command:
   git clone http://git.lan:3000/p.copissa/test.git test-http

4. On the client, create a new file, commit and push it:
   git commit -a -m "this fixes issue #1"
git push
   (specify user p.copissa and give its Gitea password when asked)

5. In the web UI, refresh the issues: Issue Rename import paths: "github.com/gogits/gogs" -> "github.com/go-gitea/gitea" #1 is now closed, as expected. Look at the file: the new file has shown up with the expected commit message.

6. On the client, redo step 3 but this time use SSH:
   git clone git@git.lan:p.copissa/test.git test-ssh

7. Redo step 4 but with issue 2:
   git commit -a -m "this fixes issue #2"
git push
   Note that no username nor password is asked. Also note that the Gitea user git has the same password as Centos git login.

8. In the web UI, refresh the issue: Issue 2 is still opened. Click on the Code tab: The commit of step 7 is there with the user name git. In fact you can choose whatever user name on the client (via git config user.name whatever and mail as well) and the commit is there bearing that name. But closing the issue always fails even when user name is the owner or a collaborator.

Expected behavior:
At step 8, issue #2 should be closed, like it was at step 2. In general, closing issues should not depend on the protocol used. If the remote server trusted the user to commit, then it should trust him to close the issue as well.

See also https://discourse.gitea.io/t/how-to-close-an-issue-with-a-commit-push/604/23 for more context.

Screenshots

[OvermindDL1]

Ah, this explains why commits don't close issues! I see this same issue.

[Etzelia]

For what it's worth, I don't have this issue and I do all my operations via SSH.
Differences in settings:
For a client I use TortoiseGit on Windows 10
My server is running Ubuntu 16.04 with a Git version of 2.7.4

[zeripath]

Hmm. You don't mention setting a key for p.copissa - how do you login through SSH?

Are you just using the generic git username and password?

If so that explains your problem. If you look at the way the authorized_keys file is created for gitea - on login with the appropriate key with id <id> the command: "gitea serv key-<id>" is run, and this sets up the appropriate environment variables for the post-commit hooks that will close issues.

If you don't login with a key that gitea knows about and manages, you will need to set those environment variables yourself.

[pcopissa]

@zeripath: I don't have a key for p.copissa. I do for git (which is also a Centos login), as I wrote above.
But the point is that git push over an HTTP URL doesn't need a key for p.copissa. It happily closes the bug without any (instead git asks for user name and password). No so for SSH: The push does happen but not the close. And to me that looks like a bug:

As I said, if the system trusts me enough to modify the remote repo, why should it not trust me for closing the issue ? Even more so when the same system DOES trust me closing when I have no key !! (i.e. when pushing over HTTP)

[pcopissa]

@Etzelia: I think I will eventually switch to TortoiseGit : It seems to work with both HTTP and SSH, whereas I have trouble with HTTP on GitExtension. (That may be down to how I installed the bits and pieces on that system. MSYS2 came first via a Ruby environment, and the GUI came later but apparently relies on its own subset of MSYS2. Not sure what happens here. And that's off topic here anyway. There is a bit more context on here )

[Etzelia]

It has nothing to do with not trusting you (I think). The likely reason that it doesn't close the issue is because your SSH key is for git, a user not associated within Gitea itself.

When you push using HTTP, you are authenticating as p.copissa, which Gitea can associate with your Gitea user, which it uses to create logs, etc. "This issue was referenced by p.copissa..."

When you push using an SSH key for git, my guess is the commit works because git has access to that repo, as it is the Centos user that Gitea itself uses. However, the SSH key is not associated with a Gitea user, therefore Gitea has no way of knowing who is trying to do what.

If I am way off base, let me know and I'll remove this comment.

EDIT: Adding comment back for reference. I re-read too hastily.
There is a git user in Gitea, however the SSH key was not managed by Gitea. So the above explanation is still plausible.

[pcopissa]

@Etzelia: That looks like a plausible mechanism.
But still... I can specify any user by setting some environment variables (as I wrote) and that user shows up as the committer (and the closer, IIRC. Will try tomorrow in the office) when pushing over HTTP...

[zeripath]

@Etzelia you were right. @pcopissa if the key is not managed by gitea then when you login with SSH, gitea will not do any permissions checks and it's hooks won't work unless you set the environment variables it needs.

[pcopissa]

So what I take from that discussion is that I have to take the trouble to set keys for each Gitea user if I want to use SSH, while I can do the same by not bothering and using HTTP(S) ?
Interesting.

[zeripath]

@pcopissa your findings of the setting environment variables meaning you're able to set yourself as any user is correct. It's why you shouldn't use non managed keys. You'll also find that apart from locked branches no permissions are checked.

Managed keys are sufficiently locked down in the authorized_keys file to prevent users from changing their environment like this (and running other commands).

[pcopissa]

@Etzelia: I re-read your comment above:

your SSH key is for git, a user not associated within Gitea itself.

Actually, I had suspected the issue was authentication or user related, so (as I wrote above) I also created a Gitea user named git and declared it as a contributor. I went as far as using the same password for Centos login git and Gitea user git. Still, that did not allow to close the issue either. So not sure what you mean by the sentence above ?

[Etzelia]

Does the Gitea user git have the SSH key installed?

[pcopissa]

SSH key installed

You mean if I sign in in Gitea web UI as (Gitea user) git, then click on the top right user avatar, then click on Settings, then click on SSH / GPG keys and I should have something there ?
If that's what you mean, then the answer is no, I never added keys there.

[Etzelia]

I think that is the likeliest cause of the issue.
The way you are using SSH, you are authenticating as a system account, not a Gitea account. Therefore, Gitea cannot associate your user with a Gitea user and run it's actions.
If you were to add the SSH key to your Gitea git user, then make sure you clone using the SSH key associated with the Gitea user, my guess is it would work as expected.

As I said, if the system trusts me enough to modify the remote repo, why should it not trust me for closing the issue ?

This would normally not be an issue, as others wouldn't have access to a system account like you do.

[zeripath]

@pcopissa yes, for SSH each user needs their own key. The key takes the place of the password and username. I don't think there's space within the git+ssh handshake to ask for an additional username and password following key authentication.

[pcopissa]

When I'm back in the office, I'll try to add keys in the web UI for user git and see what happens. The likely conclusion of all this is that I will end up using HTTP(S)...

[zeripath]

@pcopissa Does Gitlab do arbitrary user username/password login on its SSH? I remember that Sourceforge provided this - I don't think Github do though. Using SSH keys for this is very common and allows federated login without Gitea ever seeing your password.

---

Anyway you could set up your SSHD to use a PAM module that would query login with Gitea, and do some permissions check.

A basic first step might be to change SSHD to check an LDAP, and change Gitea to use that LDAP. This might be the simplest way of getting things working - however, permissions checks wouldn't happen and I don't know if you can get SSHD to map arbitrary usernames to a single username (git) - I expect it's possible though.

You'd then have to look at some way of running a command on login which could query the passed in command to find out which repository you're trying to commit to, check permissions and set the correct environment variables, but you can't just leverage gitea serv for this as it relies on key-<id> rather user-<username>. However, when you get down to doing all that you might find you're better off writing a proper PAM module yourself instead of just leveraging the LDAP module.

(A difference between GitLab and Gitea is that GitLabs hooks are what checks whether a user can commit to a repository whereas on Gitea this is mostly done in the gitea serv command meaning that if you go down this path you'll have to recreate all of that work - however it can all be done with the API.)

---

I'm not suggesting you actually do any of the above however.

[lunny]

@zeripath Gitea has supported PAM if you build with pam tag

[zeripath]

@lunny as far as I can see that's as a pam user not a pam provider?

[lunny]

Yes. pam providers authentication just like LDAP.

[pcopissa]

I did this:

1. In Gitea web UI, signed in as git,
2. In Gitea web UI, clicked on git avatar (top right corner), then selected menu Settings
3. In Gitea web UI, clicked on SSH / GPG keys tab. I see two (empty) lists labelled Manage SSH Keys and Manage GPG Keys respectively.
4. In PuTTY Key Generator, clicked on Load button, navigate to the ppk file used for setting up Pageant (see step 0b of first report). This gives me some gibberish text labelled Public key for pasting into OpenSSH authorized_keys files
5. In PuTTY key generator, copied that gibberish text.
6. In Gitea web UI, clicked on blue Add key button, right of Manage SSH Keys label. This adds a pair of edit boxes, labelled Key name and Content.
7. In Gitea web UI, pasted into the Content edit box. Key name gets populated automatically.
8. In Gitea web UI, clicked on green Add Key button (below the Content editbox).
   I get an error message (red text on pink background at top of page):
   This SSH key is already added to your account.
   This was because p.copissa Gitea user had this key inserted as well. Signed in as p.copissa, Removed the key, rerun the above sequence:
   In Gitea web UI, under the Manage SSH Keys header, I now have one entry named git@git.lan
9. In MSYS terminal (Mintty), clone the repository over SSH with user git
   git clone git@git.lan:git/test.git test-ssh
10. Modified a file, then in MSYS terminal committed and pushed it:
    git commit -a -m "this fixes issue #2"
git commit -a -m "this fixes #2"
git push
11. In Gitea Web UI, looked at issue Fix sender of issue notifications #2: It is still opened.

So it does not seem that adding git SSH public key changed anything...

Note for completeness:
Prior to step 9, I ran part of steps 0b of top post, namely setup GIT_SSH, started PAGEANT.EXE and added to Pageant the very same ppk file used at step 4+5 above.
I did try to remove Pageant from that sequence but that causes git push at step 10 to fail with a message:
fatal: protocol error: bad line length character: git@
I did try as well to run git clone at step 9 using git's CentOS password in the URL:
git clone git:password@git.lan:git/test.git test-ssh
That also fails with a similar message:
fatal: protocol error: bad line length character: Pass

[zeripath]

@pcopissa In step 9 are you being asked to provide a password (not a passphrase) to login?

• If you're being asked for a passphrase - is it possible that you've got two ssh-keys set up?
• Make sure you've posted the public key not the private key.
• Is the right key being used by your client ssh? (This can be quite hard to detect but if you change the passphrase on the correct key and then you find you're asked for the wrong passphrase - there you go.)
• Could you check: $HOME/.ssh/authorized_keys for the git user. You should have something like:

# gitea public key
command="/home/git/gitea/gitea serv key-2 --config='/home/git/gitea/custom/conf/app.ini'",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA... git@git.lan

• Check that there's only the keys that you expect in there, and that in particular you have the correct key in there.

If you're being asked for a password:

• Check that the permissions are correct on git's .ssh directory and on the authorized_keys file. eg:

$ ls -ld ~/.ssh
drwx------ 2 git git 4096 Aug 24 11:36 /home/git/.ssh
$ ls -l ~/.ssh/authorized_keys
-rw------- 1 git git 917 Aug 24 11:36 /home/git/.ssh/authorized_keys

• Check that your key isn't being rejected by your server's sshd. It could be that it's too small a key, create a 4096 bit RSA one or sufficiently large DSA one.

[zeripath]

Hmm... I've just looked at trying this on docker.

The phrase "this fixes issue #n' doesn't close the issue for either HTTP or SSH.

It needs to be 'Fixes #n' or 'fixes #n'

[pcopissa]

@zeripath:

It needs to be 'Fixes #n' or 'fixes #n'

I tried that too but the result is the same. Updated the sequence above.

[pcopissa]

@zeripath:

In step 9 are you being asked to provide a password (not a passphrase) to login?

Neither. As I wrote above, the only way I could get git to authenticate over SSH was to have the PuTTY Authentication Agent (PAGEANT.EXE) running. Specifying the key is done in Pageant GUI and at this point I am asked for the passphrase. Then never again.

Make sure you've posted the public key not the private key.

Well... As I wrote above, I copied the gibberish text from an edit box in PuTTY Key Generator that was labelled Public key for pasting into OpenSSH authorized_keys files. Is this unsuitable ?

Is the right key being used by your client ssh?

The PPK file from which Putty Key Generator derived the Public key for pasting into OpenSSH authorized_keys files is also the one that specified in PuTTY (the SSH terminal) and PuTTY logs the CentOS user git successful after I supply the passphrase, which is the same as the one asked by Pageant.exe. If I already have Pageant running, CentOS user git get logged in straight away (nothing asked).

[zeripath]

Right, tell me, can you login to a shell with this key?

If you can it's not being managed by gitea and it's likely duplicated in the authorized_keys file. What are the contents of the git user's authorized_keys file? Please feel free to censor the keystring but tell me of there are duplicated keystrings in the file - that's very important.

Have you tried creating a new SSH key and putting in to gitea only? Do not add this new key into anything else to do with your centos box. If you're not able to commit/clone/pull with this new key then we know that there is something wrong with the way that your gitea installation is dealing with keys.

Edit: you should not be able to log in to a shell with a Gitea managed key.

[zeripath]

I think it might be worth putting down some information about how gitea manages git over SSH.

---

1. There are two main routes, gitea's internal SSH or the external SSH.
2. If you're running the internal SSH then assuming you're running gitea as the git user, and you've otherwise not done further configuration you will not be running SSH for gitea over port 22.
3. In which case is likely that gitea's SSH server is running on port 2222, but AFAIK gitea would be showing it's clone paths with the port in there.
4. Gitea's internal SSH does not allow people to log in to a shell so in your case if you can get to a shell you are not connecting to gitea's own SSH server.
5. You can find out if you're running the internal SSH by looking at the configuration on the admin pages and by checking if port 2222 is open to be connected.
6. Assuming you're using the "external" SSH server - which I think is the default.
7. Gitea manages logins by writing to the .ssh/authorized_keys file for the user running Gitea by default. Therefore if the git user is running this should be in the git user's home directory. If it is not running as the git user then logging into git will not be using Gitea's authorized_keys file.
8. Gitea will ensure that this file and directory has the correct permissions for the default openSSHd configuration.
9. Gitea will add key lines as described above for each key it is told to manage. The key line is of note because it has a command option which in the default sshd configuration gets run instead of whatever command the SSH session says to run and instead of a shell. Other options tell sshd to restrict the session in other ways.
10. This command restricts what can commands can be run when logged in and sets up variables for the hooks.
11. In particular if this command is run you cannot run a shell. So if you can SSH to the server as the git user and get a command prompt you are not logging in by matching a Gitea line in the authorized_keys file.

Gitea is making several assumptions here:

a. SSHD is configured to allow authorized_keys files for users.
b. It's configured for the git user to have an authorized_keys.
c. The git user's authorized_keys file is supposed to be in the git's $HOME/.ssh/authorized_keys
d. The sshd server is configured to allow authorized_keys files to set the above options
e. If sshd has an AuthorizedKeysCommand set up for the git user then we are assuming that our key isn't matched by that command - otherwise Gitea's line will not be read.
f. If our key is in the authorized_key file multiple times, only the first line will be matched. If that is not Gitea's line then Gitea's command will not run.
g. Assuming we match a Gitea line the command option has to be able to run - if the command is not runnable we will not be able to log in. Further it has to be the correct command with the correct options, so if it is not run correctly the hooks won't run correctly.

There are therefore several things that can go wrong in the case of a non default install. Especially if some other software is trying to be helpful and manages SSH keys itself.

Assuming that none of those are the problem then we then have to consider the issue that the post-commit hooks aren't being run correctly - however this is a little odd as you tell me that they're running on http.

[pcopissa]

Sorry but I got stuck with Windows 10 updates for the past 120mn :/

Right, tell me, can you login to a shell with this key?

Yes. The key predates the Gitea experiments. It's purpose was password-less login. And this works. And worked before Gitea came into the picture. At that time, the CentOS machine had a DNS CNAME record linux.lan. It now also has a CNAME record git.lan. They point to the same fully qualified name.

If you can it's not being managed by gitea and it's likely duplicated in the authorized_keys file.

It is duplicated on the server in ~git/.ssh/authorized_keys (this same key is present in that file, twice, see below)

What are the contents of the git user's authorized_keys file?
On the CentOS server:

$ cat authorized_keys
ssh-rsa AAAAB3...DEGoFbuQ== git@linux.lan

# gitea public key
command="/usr/local/bin/gitea serv key-4 --config='/etc/gitea/app.ini'",no-port-
forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3...DEGoFbuQ== git@git.lan

$ ssh-keygen -lf authorized_keys
2048 SHA256:5cvv/0BHDiOAi/NZXoGpyF4Aii7LFmbPLqBeM5vlbQo git@linux.lan (RSA)
2048 SHA256:5cvv/0BHDiOAi/NZXoGpyF4Aii7LFmbPLqBeM5vlbQo git@git.lan (RSA)

On my MSYS client, I copied the string mentionned at step 4 into a file called pubkey-from-ppk.txt and ran:

$ ssh-keygen.exe -lf pubkey-from-ppk.txt
2048 SHA256:5cvv/0BHDiOAi/NZXoGpyF4Aii7LFmbPLqBeM5vlbQo git@linux.lan (RSA) 

Have you tried creating a new SSH key and putting in to gitea only?

No

Do not add this new key into anything else to do with your centos box. If you're not able to log in with this new key then we know that there is something wrong with the way that your gitea installation is dealing with keys.

This will have to wait untli Monday.

[zeripath]

Ok so the fact that the key is duplicated in the authorized_keys file explains your problem. When you log in with that key, the first line is matched and so you never get the gitea command called. That breaks the post-commit hook and you'll find that you get no permissions checked either.

You either have to get rid of that first line, meaning you can't log in to a shell with that key, or use a different key. (A third option is to write a bash script that checks if you're trying run a git command and then passes to the appropriate gitea serv command, or else just runs the command/shell and set that script as the command option on the first mention of your key... There are many issues with this option.)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.