Unable to use SSH with Gitea

LTM · 2 August 2021 02:47

I am trying to enable SSH on my Gitea instance. Though I feel like I have done everything right to achieve this including the guide that Gitea recommends, I am unable to push anything to my Gitea instance via SSH. I am able to push via HTTP.

One of the things I am trying to do is to use this guide to automate backups of my Home Assistant config files. I have followed the guide multiple times (after deleting previous work like the .ssh folder and even known_hosts in the system .ssh folder. I have even tried a clean install of dietpi.) and when I get to the part where I try to push the commit to my repo (git push -u origin master), I get a return asking for a password even though I have already generated a key and posted the public key to the repository (and have also tried posting it to the account as a whole). I also made sure to give write permissions to the repo. This is the response I get:

➜ /config git:(master) git push -u origin master
dietpi@dietpi.sudo> 's password:
fatal: ‘ltm/Home-Assistant-Backup.git’ does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I have also tried to make a key pair on my desktop and adding it to the account using the same guide to add one to Github and am unable to connect.

Here is my Gitea [server] config in custom/app.ini:

[server]
SSH_DOMAIN       = dietpi.sudo
DOMAIN           = dietpi.sudo
HTTP_PORT        = 3000
ROOT_URL         = http://dietpi.sudo:3000/
DISABLE_SSH      = false
SSH_PORT         = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /mnt/dietpi_userdata/gitea/data/lfs
LFS_JWT_SECRET   = [redacted]
OFFLINE_MODE     = true

I am hoping someone can shed some light and point me in the right direction to be able to get SSH working.

Thanks

trendy · 3 August 2021 09:05

Are you able to connect from an SSH client like Putty? This error seems to be related to git, not SSH.

Joulinar · 3 August 2021 09:21

yep, SSH seems to be working. It looks more like Git repository did not exist

fatal: 'ltm/Home-Assistant-Backup.git' does not appear to be a git repository
fatal: Could not read from remote repository.

LTM · 3 August 2021 16:32

Yes, SSH is working fine, but I can not do anything with pushing or pulling from Gitea. The repository does exist. I pulled the SSH url directly from the Gitea UI repository page.

The only way to get that message up is if I enter in the password for the dietpi user. It does not work with key pair files at all like it should using SSH.

To get rid of the repository not existing message, I have to enter in the full path to the git file like “dietpi@dietpi.sudo:/mnt/dietpi_userdata/gitea/gitea-repositories/ltm/Home-Assistant-Backup.git” in the git config file for origin. It does work, but seems to be a very hacky solution to me and does not fix why I have to enter in a password when it should be using a key pair.

Joulinar · 3 August 2021 21:40

does your SSH key is working using putty? Did you tried to use OpenSSH server instead of Dropbear? Sometimes this makes a difference as Dropbear has less functions compare to OpenSSH. But this would require new keys

LTM · 3 August 2021 22:25

Yes, my SSH key works while using PuTTY. I am using OpenSSH (one of the first things I do on a fresh installation) and made sure dropbear was cleanly uninstalled.

I did a fresh install today with new keys and everything and have came to the same result. My thoughts are still along the lines of a permissions issue between Gitea and the system but I can not find any sort of logs to back that claim up.

I may try to mess with the Gitea internal SSH server tonight to see if I can get it working that way.

Joulinar · 3 August 2021 22:29

Maybe you can open an issue at Gitea https://github.com/go-gitea/gitea/issues in parallel. Maybe these guys have some better experience than we have.

LTM · 4 August 2021 14:19

I hopped on the Gitea Discord server and made some headway on this.

Basically, the correct way the devs (I actually talked with a dev) very highly recommend is to create a separate user for Gitea. I did this by using “adduser” listed in the official documentation and modified the home directory to be “/mnt/dietpi_userdata/gitea”:

adduser \
   --system \
   --shell /bin/bash \
   --gecos 'Git Version Control' \
   --group git\
   --disabled-password \
   --home /mnt/dietpi_userdata/gitea \
   git

Next, I created the ssh directory and created the authorized_keys file that I will be using:

mkdir /mnt/dietpi_userdata/gitea/.ssh && touch /mnt/dietpi_userdata/gitea/.ssh/authorized_keys

Next, I changed the gitea directory to be recursively owned by the new git user:

chown -R git:git /mnt/dietpi_userdata/gitea

Next, I edited “/etc/systemd/system/gitea.service” to run the service to run as the git user:

[Unit]
Description=Gitea (DietPi)

[Service]
User=git
WorkingDirectory=/mnt/dietpi_userdata/gitea/gitea-repositories
Environment=USER=git HOME=/mnt/dietpi_userdata/gitea
ExecStart=/mnt/dietpi_userdata/gitea/gitea web

[Install]
WantedBy=multi-user.target

Next, I edited the app.ini file to reflect the changes we made:

nano /mnt/dietpi_userdata/gitea/custom/conf/app.ini

Change “RUN_USER = dietpi” to “RUN_USER = git”
Under [server], add the line under “DISABLE_SSH”:

SSH_ROOT_PATH    = /mnt/dietpi_userdata/gitea/.ssh

Next, I took the recommended precaution to secure a couple of things a little bit:

chmod 750 /mnt/dietpi_userdata/gitea && chmod 640 /mnt/dietpi_userdata/gitea/custom/conf/app.ini

Finally, I had to restart the system. I couldn’t just restart Gitea because even though I restarted the service, it was still running under the dietpi user when it needs to be running under the new user. After restarting the system, everything is working as it should.

Joulinar · 4 August 2021 22:16

Ok running as own user might be a good idea but on DietPi usually application user will be setup with /usr/sbin/nologin option, means user is not able to login via SSH. This would not fix your issue. Btw, this is best practice and a security aspect. Next to this, setting up SSH key access would be an own, user individual setting, anyway.

MichaIng · 7 August 2021 11:44

/usr/sbin/nologin is not necessarily an issue, as the SSH client may pass an own command here, to perform the Git action. But needs to be tested, of course. If required, we can change the default shell to /bin/dash while still keeping the password disabled.

LTM · 11 August 2021 16:49

I have /bin/bash/ set up when creating the user. Does this mean that that user can only use bash or is it used as a default?

MichaIng · 14 August 2021 10:57

When you create the user via useradd … -s /bin/bash …, then bash will be the default shell that opens when e.g. connecting via SSH, do a login on local console, sudo -s/-i etc. But as long as you get into a shell, from there you can open any other type of shell. For a service user, where no interactive console is wanted but only a single command shall be passed via SSH, I’d use /bin/dash btw, which is much lighter, opens faster, less RAM usage, faster command execution .

WarHawk · 14 August 2021 17:15

possible mismatch with the ssh daemon…might need to install openssh instead of dropbear

The install script for Gitea might change that though

MichaIng · 16 August 2021 18:39

I remember now this: https://github.com/MichaIng/DietPi/issues/4380
A client tool included with the OpenSSH client package, which copies the public SSH key in place, but does it wrong when it sees Dropbear as server, as OpenWRT uses Dropbear as well, but with a very uncommon setup.