Unable to push to remote

Install/Maintain/Configure
1

I have been trying some things for the last few hours, but nothing worked. The wit’s end is already a fargone memory.

The situation is like this: I just made a new server to handle some random stuff: have a blog, a git repo, small scale really. Set a few basic things, everything working so far: Apache, a www folder, PHP/MySQL, .confs for the domain and subdomains, Let’s Encrypt.

I have a git user which controls all source-related files and folders, plus a /home/git folder to itself so the application repos can be stored there.

So I got Go, set the paths, got Gitea from source and compiled it. Changed to the git user, ran gitea web. Went through the install process, everything claimed to be working fine.

Log in with a user, add a public key. I’m making sure to add it explicitly on Windows - all consoles seem to have a lot of trouble with forgetting them.

For testing, I try a direct connection. ssh git@git.address.com gives me the Hi there, You've successfully authenticated message.

I make a new repository on the website, and clone it locally using HTTPS. Make a change, add and commit it, and try pushing it to remote.

remote: invalid credentials
fatal: Authentication failed for 'https://git.address.com/username/Repository.git/'

Trying to use the SSH link, I have the following:

git clone git@git.address.com:username/Repository.git

and then it asks my password, then fails due to a permission denied.

I am at a complete loss at what even could be my next step in troubleshooting. I wonder if anyone’s got an idea?

My app.ini is as follows, with mere substitutions to anonymize it.

APP_NAME = Gitea
RUN_USER = git
RUN_MODE = prod

[security]
INTERNAL_TOKEN = prettylongstring
INSTALL_LOCK   = true
SECRET_KEY     = secretkeyhash

[database]
DB_TYPE  = mysql
HOST     = 127.0.0.1:3306
NAME     = gitea
USER     = dbuser
PASSWD   = dbpassword
SSL_MODE = disable
PATH     = data/gitea.db

[repository]
ROOT = /home/git/gitea-repositories

[server]
SSH_DOMAIN       = git.address.com
DOMAIN           = localhost
HTTP_PORT        = 3000
ROOT_URL         = https://git.address.com/
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /opt/go/src/code.gitea.io/gitea/data/lfs
LFS_JWT_SECRET   = secrethash
OFFLINE_MODE     = false

[mailer]
ENABLED = false

[service]
REGISTER_EMAIL_CONFIRM            = false
ENABLE_NOTIFY_MAIL                = false
DISABLE_REGISTRATION              = false
ENABLE_CAPTCHA                    = false
REQUIRE_SIGNIN_VIEW               = false
DEFAULT_KEEP_EMAIL_PRIVATE        = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING       = true
NO_REPLY_ADDRESS                  = noreply.example.org

[picture]
DISABLE_GRAVATAR        = false
ENABLE_FEDERATED_AVATAR = true

[openid]
ENABLE_OPENID_SIGNIN = true
ENABLE_OPENID_SIGNUP = true

[session]
PROVIDER = file

[log]
MODE      = file
LEVEL     = Info
ROOT_PATH = /opt/go/src/code.gitea.io/gitea/log

What else could be useful as far as information needed to figure this out?

2

Hi phydeaux

First of all the logs at the time of this error would be a great help.
Second, have you checked the folder permissions?
Third, have you tried updating authorized_keys file and resyncing of gitea hooks via admin panel on web UI?

3

Folder permissions seem fine - /home/git and everything inside is owned by git.
Yep, tried updating authorized keys and resyncing multiple times. I have about 7 gitea_bak files from previous versions of it. The current one contains the command parameter and my current public key.

gitea.log just says
2018/05/16 21:08:32 [...routers/repo/http.go:153 HTTP()] [E] invalid credentials 2018/05/16 21:08:33 [...routers/repo/http.go:153 HTTP()] [E] invalid credentials

…And I have absolutely no idea how, while retesting things here to get logs, changing the repository’s .git/config file to make [origin] point to the given SSH address instead of the HTTPS variation I used when cloning it let it push successfully somehow. It wasn’t before, I swear.

Am I missing more than one very important thing here? I probably approached everything with the wrong perspective from the beginning. It’s probably fine enough for me to work with only SSH operations. But then, why doesn’t HTTPS work? /var/log/auth.log or Apache’s log didn’t say anything useful about it either.

4

Hi phydeaux

Think the SSH cloning does indeed work now because of updating the authorized_keys file.
But the reason why HTTPS doesn’t work is still unclear to me.

Could you set the log level in app.ini to “Debug” and repeat the steps? Perhaps this provides a more detailed log output.
Unfortunately I don’t have experience with Apache’s reverse proxy configuration. I use nginx for that purpose.

best regards
daviian