Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gitea keys fails: Forbidden attempt to access internal url #17497

Closed
rmsc opened this issue Oct 30, 2021 · 5 comments
Closed

gitea keys fails: Forbidden attempt to access internal url #17497

rmsc opened this issue Oct 30, 2021 · 5 comments

Comments

@rmsc
Copy link
Contributor

rmsc commented Oct 30, 2021

Gitea Version

1.15.6-rootless

Git Version

No response

Operating System

No response

How are you running Gitea?

I'm running the "gitea:1.15.6-rootless" docker image under rootless podman.

Database

MySQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/rmsc/b4bcdec9ee84cd67a2ed2f1870ce73d2

Description

I'm using gitea keys in an AuthorizedKeysCommand. It used to work in at least in version 1.15.4, but is not working anymore, and is failing with a weird error:

$ sudo -u git /usr/bin/podman exec -it gitea-app /usr/local/bin/gitea keys -u git -t ed_25519 -k <REDACTED>
2021/10/30 22:02:52 main.go:117:main() [F] Failed to run app with [/usr/local/bin/gitea keys -u git -t ed_25519 -k <REDACTED>]: Failed to update public key: readObjectStart: expect { or n, but found F, error found in #1 byte of ...|Forbidden
	|..., bigger context ...|Forbidden
	|...

The error happens regardless of whether the key is correct or not. The server log reports a Forbidden attempt to access internal url, as per the provided log gist.

Screenshots

No response

EDIT: I'm not so sure I was using the rootless version of 1.15.4 when it worked.

@zeripath
Copy link
Contributor

$ sudo -u git /usr/bin/podman exec -it gitea-app /usr/local/bin/gitea keys -c /path/to/app.ini -u git -t ed_25519 -k <REDACTED>

@rmsc
Copy link
Contributor Author

rmsc commented Oct 31, 2021

That did help, thanks! Now I get:

$ sudo -u git /usr/bin/podman exec -it gitea-app /usr/local/bin/gitea keys -c /etc/gitea/app.ini -u git -t ed_25519 -k <REDACTED>
2021/10/31 07:52:12 main.go:117:main() [F] Failed to run app with [/usr/local/bin/gitea keys -c /etc/gitea/app.ini -u git -t ed_25519 -k <REDACTED>]: Failed to update public key: public key does not exist [id: 0]
2021/10/31 07:52:12 Started POST /api/internal/ssh/authorized_keys for [::1]:51002
2021/10/31 07:52:12 Completed POST /api/internal/ssh/authorized_keys 500 Internal Server Error in 991.758µs

The key does exist.

One thing that is weird is that there are 3 config files in the system:

  • /etc/gitea/app.ini containing the main configuration
  • /etc/gitea/conf/app.ini containing the INTERNAL_TOKEN
  • /var/lib/gitea/custom/conf/app.ini also containing the INTERNAL_TOKEN

I would expect the main config to sit in /etc/gitea/conf/app.ini so that it's picked up by the cli. Any reason why that isn't the case?

@rmsc
Copy link
Contributor Author

rmsc commented Oct 31, 2021

My bad, the key type I was entering was wrong. It should have been -t ssh-ed25519 instead of -t ed_25519. Now AuthorizedKeysCommand works fine. Thanks!

Now regarding the config files, I did a clean install on a new VM, and now the only configuration file is /etc/gitea/app.ini. Any reason for that location rather than /etc/gitea/conf/app.ini?

@rmsc rmsc closed this as completed Oct 31, 2021
@zeripath
Copy link
Contributor

OK I think it's time we start compiling the docker build with the appropriate linker commands so that gitea just looks in the right places without having to use -c

@rmsc
Copy link
Contributor Author

rmsc commented Oct 31, 2021

@zeripath that would be great!

zeripath added a commit to zeripath/gitea that referenced this issue Oct 31, 2021
Too many docker users are caught out by the default location for the
app.ini file being environment dependent so that when they docker exec
into the container the `gitea` commands do not work properly and require
additional `-c` arguments to correctly pick up the configuration.

This PR simply builds the default locations into the build.

Fix go-gitea#14468
Reference go-gitea#17497
Reference go-gitea#12082
Reference go-gitea#8941
 ... amongst others ...

Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath added a commit to zeripath/gitea that referenced this issue Nov 28, 2021
Too many docker users are caught out by the default location for the
app.ini file being environment dependent so that when they docker exec
into the container the gitea commands do not work properly and require
additional -c arguments to correctly pick up the configuration.

This PR simply shadows the gitea binary using variants of the FHS
compatible script to make the command gitea have the default locations
by default.

Fix go-gitea#14468
Reference go-gitea#17497
Reference go-gitea#12082
Reference go-gitea#8941
... amongst others ...
Replace go-gitea#17501

Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath added a commit that referenced this issue Dec 1, 2021
Too many docker users are caught out by the default location for the
app.ini file being environment dependent so that when they docker exec
into the container the gitea commands do not work properly and require
additional -c arguments to correctly pick up the configuration.

This PR simply shadows the gitea binary using variants of the FHS
compatible script to make the command gitea have the default locations
by default.

Fix #14468
Reference #17497
Reference #12082
Reference #8941
... amongst others ...
Replace #17501

Signed-off-by: Andrew Thornton <art27@cantab.net>
Chianina pushed a commit to Chianina/gitea that referenced this issue Mar 28, 2022
Too many docker users are caught out by the default location for the
app.ini file being environment dependent so that when they docker exec
into the container the gitea commands do not work properly and require
additional -c arguments to correctly pick up the configuration.

This PR simply shadows the gitea binary using variants of the FHS
compatible script to make the command gitea have the default locations
by default.

Fix go-gitea#14468
Reference go-gitea#17497
Reference go-gitea#12082
Reference go-gitea#8941
... amongst others ...
Replace go-gitea#17501

Signed-off-by: Andrew Thornton <art27@cantab.net>
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants