Problems with gitea on a NAS in home setup - Install/Maintain/Configure

Install/Maintain/Configure

2

2

rogerp

Jan 2024

I have installed Gitea on my Asustor NAS: the “server”

I don’t use an external (cloud) service. I simply want to be able to use two “client” computers at home to do my (hobby) coding. Both run Arch Linux. I don’t want/need a signed CA certificate, I don’t have a domain as such, just an IP address:3100 for the server.

I have used ssh-keygen and added the private key to the ssh-agent and saved the public key on the Gitea server and verified it.

I have also set up a GPG key and installed and verified it using gitea. I have followed this Github setting up a GPG verification

I use vscode and have installed the VS Code Git extension.

So, my client (local) git communicates with my gitea service over SSL (I assume). I’m a bit confused here as I don’t know what actually happens. For SSH, my NAS advises me to use a port other than 22 for security. I have configured sshd to use the correct port and it seems to be able to talk to the server because, if I just ssh in, the NAS responds by asking me for a password an it’s talk over the correct port.

I have created an empty repository in gitea. I am not an organisation and thus I don’t have a domain name. The repository looks fine, it shows two urls, one for HTTPS and one for SSH. I’ve tried using both.

I obviously have an account on the NAS and a different username (see below) and password for gitea. So here are three questions:

I have probably got confused with all the options and muddled up my SSH and GPG key generation. It’s the identity/“exact IP address” thing.

Each time I make a change I re-run git init. I want to push my code to this empty repository. I get the following from git, within vscode

Whys is the path name a concatenation of my local filepath and the remote path?

Later in the error log I get:

…which is SSL specific, even though I thought I had configured git globally to use GPG.

How would you advise me to configure my set-up? I have lost count of the hours/days I have spent on this! Sorry it’s so long but I am trying to explain everything as carefully as poss.

2

2

1 month later

deximer

Feb 2024

A likely problem is that you are not setting the git ssh port to 3122 on clone. On Asustor NAS, Gitea runs in a Docker container and maps port 22 to 3122 so as not to conflict to the NAS ssh service. This means you need to tell git to use 3122:

git clone ssh://git@host:3122/user/repo.git

This will connect to the ssh server in the gitea Docker and everything will work. The git user is in the Docker image and is preconfigured to “just work” as long as you connect to the gitea ssh server on port 3122. Note that the “ssh://” is required. Once you have the repo cloned you’ll never have to worry about the alternate port number as the repo config will have it mapped.

You can get better insite into the Docker setup by installing “ portainer.io ” from the NAS app center. This app will show you all your containers and their mapped ports.

rogerp

Feb 2024

@deximer Many thanks for your reply. I have used port 3122, and checked that it is open on the disk server. I also double-checked my gpg and ssh keys. Everything is in order. I have also installed portaina.io and find it very useful but it hasn’t helped me figure out what I’m doing wrong.

The bit I don’t understand is whether I should set up the identity “git” as a user. Typing git@[ip address] seems to me that the server should recognise git as an ordinary user. I have of course tried using the only two authorised users, i.e. admin and my own login. But I normally have admin disabled and wouldn’t use it normally. Just thought it was worth a try.

I have also changed my password to make sure I know that I am typing it correctly when prompted. I am sure it’s not the password that’s keeping me out though.

Roger

deximer

Feb 2024

The container Gitea is running in does have a user “git.” You can log into a shell in the running container using portainer, look in the /etc/passwd file and see the git “user” defined. But you should not need to worry about that at all and tampering with it will lead to no good.

You might try disabling SSL to see if that is your problem. Do this on your local system:

git config --global http.sslVerify false

Try accessing a repo. If it works you at least know that SSL is the source of the problem. Do make sure to re enable SSL:

git config --global http.sslVerify true

You can see how your local git is configured for SSL with:

git config --global http.sslBackend

The output could be empty or “openssl”, “schannel” (or maybe “gnutils”). From here you can try a few things.

If your sslbackend in one of the above, try the other. e.g. if it is “openssl” try:

git config --global http.sslBackend schannel

You can try unsetting the backend:

git config --global --unset http.sslBackend

If none of that works, be sure to return sslBackend to the original setting.

I’m traveling so can’t view my local server but maybe some of that will work.