&#39;git push&#39; over SSH does not close issues, but does over HTTP(S). #2417

@zeripath commented on GitHub (Oct 24, 2018):

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.

@zeripath commented on GitHub (Oct 24, 2018): 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.

GiteaMirror commented

@pcopissa commented on GitHub (Oct 24, 2018):

@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 commented on GitHub (Oct 24, 2018): @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)

GiteaMirror commented

@pcopissa commented on GitHub (Oct 24, 2018):

@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 )

@pcopissa commented on GitHub (Oct 24, 2018): @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]( https://discourse.gitea.io/t/how-to-close-an-issue-with-a-commit-push/604/23) )

GiteaMirror commented

@Etzelia commented on GitHub (Oct 24, 2018):

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.

@Etzelia commented on GitHub (Oct 24, 2018): 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.

GiteaMirror commented

@pcopissa commented on GitHub (Oct 24, 2018):

@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...

@pcopissa commented on GitHub (Oct 24, 2018): @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...

GiteaMirror commented

@zeripath commented on GitHub (Oct 24, 2018):

@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.

@zeripath commented on GitHub (Oct 24, 2018): @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.

GiteaMirror commented

@pcopissa commented on GitHub (Oct 24, 2018):

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.

@pcopissa commented on GitHub (Oct 24, 2018): 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.

GiteaMirror commented

@zeripath commented on GitHub (Oct 24, 2018):

@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).

@zeripath commented on GitHub (Oct 24, 2018): @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).

GiteaMirror commented

@pcopissa commented on GitHub (Oct 24, 2018):

@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 ?

@pcopissa commented on GitHub (Oct 24, 2018): @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 ?

GiteaMirror commented

@Etzelia commented on GitHub (Oct 24, 2018):

Does the Gitea user git have the SSH key installed?

@Etzelia commented on GitHub (Oct 24, 2018): Does the Gitea user git have the SSH key installed?

GiteaMirror commented

@pcopissa commented on GitHub (Oct 24, 2018):

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.

@pcopissa commented on GitHub (Oct 24, 2018): > 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.

GiteaMirror commented

@Etzelia commented on GitHub (Oct 24, 2018):

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.

@Etzelia commented on GitHub (Oct 24, 2018): 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.

GiteaMirror commented

@zeripath commented on GitHub (Oct 24, 2018):

@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.

@zeripath commented on GitHub (Oct 24, 2018): @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.

GiteaMirror commented

@pcopissa commented on GitHub (Oct 24, 2018):

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)...

@pcopissa commented on GitHub (Oct 24, 2018): 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)...

GiteaMirror commented

@zeripath commented on GitHub (Oct 24, 2018):

@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.

@zeripath commented on GitHub (Oct 24, 2018): @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.

GiteaMirror commented

@lunny commented on GitHub (Oct 25, 2018):

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

@lunny commented on GitHub (Oct 25, 2018): @zeripath Gitea has supported PAM if you build with `pam` tag

GiteaMirror commented

@zeripath commented on GitHub (Oct 25, 2018):

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

@zeripath commented on GitHub (Oct 25, 2018): @lunny as far as I can see that's as a pam user not a pam provider?

GiteaMirror commented

@lunny commented on GitHub (Oct 25, 2018):

Yes. pam providers authentication just like LDAP.

@lunny commented on GitHub (Oct 25, 2018): Yes. `pam` providers authentication just like LDAP.

GiteaMirror commented

@pcopissa commented on GitHub (Oct 25, 2018):

I did this:

In Gitea web UI, signed in as git,
In Gitea web UI, clicked on git avatar (top right corner), then selected menu Settings
In Gitea web UI, clicked on SSH / GPG keys tab. I see two (empty) lists labelled Manage SSH Keys and Manage GPG Keys respectively.
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
In PuTTY key generator, copied that gibberish text.
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.
In Gitea web UI, pasted into the Content edit box. Key name gets populated automatically.
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
In MSYS terminal (Mintty), clone the repository over SSH with user git
git clone git@git.lan:git/test.git test-ssh
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
In Gitea Web UI, looked at issue #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

@pcopissa commented on GitHub (Oct 25, 2018): 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). <del>I get an error message (red text on pink background at top of page): `This SSH key is already added to your account.`</del> 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: <del>`git commit -a -m "this fixes issue #2"`</del> `git commit -a -m "this fixes #2"` `git push` 11. In Gitea Web UI, looked at issue #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`

GiteaMirror commented

@zeripath commented on GitHub (Oct 25, 2018):

@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 commented on GitHub (Oct 25, 2018): @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.

GiteaMirror commented

@zeripath commented on GitHub (Oct 25, 2018):

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'

@zeripath commented on GitHub (Oct 25, 2018): 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'

GiteaMirror commented

@pcopissa commented on GitHub (Oct 26, 2018):

@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 commented on GitHub (Oct 26, 2018): @zeripath: > It needs to be 'Fixes #n' or 'fixes #n' I tried that too but the result is the same. Updated the sequence above.

GiteaMirror commented

@pcopissa commented on GitHub (Oct 26, 2018):

@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).

@pcopissa commented on GitHub (Oct 26, 2018): @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).

GiteaMirror commented

@zeripath commented on GitHub (Oct 26, 2018):

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 commented on GitHub (Oct 26, 2018): 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.

GiteaMirror commented