[Documentation] How to "set the environment properly"? #4947

New Issue

GiteaMirror · 2025-11-02T06:08:38-06:00

GiteaMirror commented

2025-11-02 06:08:38 -06:00

Originally created by @ki9us on GitHub (Feb 26, 2020).

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.

Originally created by @ki9us on GitHub (Feb 26, 2020). 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](https://docs.gitea.io/en-us/config-cheat-sheet/#security-security): > 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](https://docs.gitea.io/en-us/specific-variables/).

GiteaMirror added the type/question label 2025-11-02 06:08:38 -06:00

GiteaMirror closed this issue

2025-11-02 06:08:38 -06:00

GiteaMirror commented

2025-11-02 06:08:39 -06:00

@jolheiser commented on GitHub (Feb 26, 2020):

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.

@jolheiser commented on GitHub (Feb 26, 2020): 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.

GiteaMirror commented

2025-11-02 06:08:39 -06:00

@guillep2k commented on GitHub (Feb 26, 2020):

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

@guillep2k commented on GitHub (Feb 26, 2020): @keith24 it means you are trying to bypass Gitea by not using the proper remote for your copy of the repository: ![image](https://user-images.githubusercontent.com/18600385/75395089-663df600-58d0-11ea-852f-87740ed46fe0.png) 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.

GiteaMirror commented

2025-11-02 06:08:39 -06:00

@castrov commented on GitHub (Mar 3, 2020):

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

@castrov commented on GitHub (Mar 3, 2020): @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 <new git home dir>/.ssh/authorized_keys. I solved it for me using a symlink.

GiteaMirror commented

2025-11-02 06:08:40 -06:00

@ki9us commented on GitHub (Mar 22, 2020):

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.

@ki9us commented on GitHub (Mar 22, 2020): 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.

GiteaMirror commented

2025-11-02 06:08:40 -06:00

@fkockmeyer commented on GitHub (Jun 7, 2020):

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.

@fkockmeyer commented on GitHub (Jun 7, 2020): 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.

GiteaMirror referenced this issue

2025-11-02 14:09:28 -06:00

[PR #4975] [MERGED] Fix preview when adding new code review comment #17573

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#4947