Gitea: [Documentation] How to "set the environment properly"?

[keith24]

This is the error I got when pushing changes over SSH:

remote: Gitea: Rejecting changes as Gitea environment not set.
remote: If you are pushing over SSH you must push with a key managed by
remote: Gitea or set your environment appropriately.

From the docs: Config Cheat Sheet:

ONLY_ALLOW_PUSH_IF_GITEA_ENVIRONMENT_SET: true: Set to false to allow local users to push to gitea-repositories without setting up the Gitea environment. This is not recommended and if you want local users to push to gitea repositories you should set the environment appropriately.

Is it just me or are the error and documentation a little vague? I don't understand what environment needs to be set. Googling just brought up the doc on specific variables.

[jolheiser]

This message should only appear if you are bypassing Gitea and pushing directly to a repository.
In general this leads to irregular behavior and is not recommended.

[guillep2k]

@keith24 it means you are trying to bypass Gitea by not using the proper remote for your copy of the repository:

You normally use:

git clone {....address-from-gitea.....}

And then you can push your changes there. If you've already have your changes in a local copy and you want to use those and push to Gitea, you can:

# Remove previous "origin"
git remote remove origin
# Add Gitea as "origin"
git remote add origin {....address-from-gitea.....}

{....address-from-gitea.....} is the HTTP or SSH address for your repo, as exposed in the box shown above.

[castrov]

@keith24 Lately I was encountering the same problem. In my case the problem was that gitea did not find the correct .ssh/authorized_keys file. In my installation I had to move the home directory of the git user. When adding a SSH key via UI the key was added to /home/git/.ssh/authorized_keys and not /.ssh/authorized_keys.
I solved it for me using a symlink.

[keith24]

I _had_ been trying to push an already-existing repo to gitea. But I _did_ replace the remote with the SSH URL that gitea provided. IIRC it was actually the same as the one I'd already had.

@castrov was probably having the same issue as me: I was using the ssh keys from the server, not managing them in git. Maybe the URL was the same, but git assumed the original ssh identity because that's what it had a key for.

I just started using HTTPS and forgot I ever had this issue (sorry about not replying).

I'm gonna close this for now because I'm not having any issue anymore. Whether some of the information in this thread should go in the docs is up to the maintainers' discretion.

[fkockmeyer]

For all who are still facing this issue. Please check, if your user you are using to run gitea (e.g git or gitea) is set up without a password, try to disable empty passwords in your sshd.config file by setting PermitEmptyPasswords to No. You can do this in the Match User section to set this only for the gitea user. You should also check the configuration for your authorized_keys file and if the file contains the expected configuration.