DietPi-Software | Gitea: Run as system user with SSH key option

[LilTrublMakr]

Creating a bug report/issue

Required Information

• DietPi version |
  G_DIETPI_VERSION_CORE=7
  G_DIETPI_VERSION_SUB=4
  G_DIETPI_VERSION_RC=2
  G_GITBRANCH='master'
  G_GITOWNER='MichaIng'
  G_LIVE_PATCH_STATUS[0]='not applied'

• Distro version |
  buster 10.10

• Kernel version |
  Linux DietPi 5.10.52-v8+ 1440 SMP PREEMPT Tue Jul 27 09:56:40 BST 2021 aarch64 GNU/Linux

• SBC model |
  RPi 4 Model B (aarch64)

• Power supply used |
  Ofiicial power supply

• SDcard used |
  Samsung 128GB

Additional Information (if applicable)

• Software title |
  Gitea

• Was the software title installed freshly or updated/migrated?
  Fresh install

• Can this issue be replicated on a fresh installation of DietPi?
  Yes

Steps to reproduce

1. Install Gitea
2. Configure app.ini
3. Create repo
4. Add deploy key to repo
5. Try to push to repo

Expected behaviour

1. Repo should be pushed to Gitea without asking for host password

Actual behaviour

➜  /config git:(master) ✗ git push -u origin master
dietpi@dietpi.sudo's password: (enter in password)
fatal: 'dietpi@dietpi.sudo:user/repo.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.

(Should not be asking for a password and using SSH)

Extra details

After posting this issue on the forums, I spoke with the Gitea devs on their discord server. They said that it is strongly suggested and basically required to create a separate user for git operations. I spent a little bit of time with them to get a proposed fix that should be decently easy to implement. I have not tested this on a new installation (meaning that I have not edited dietpi_software with the fixes and tried installing it) but would be able to early next week if needed.

Forum post with needed changes to fix: https://dietpi.com/phpbb/viewtopic.php?p=36607#p36607

[Joulinar]

Hi,

There wouldn't be a need to open the issue on GitHub as well. Forum as well as GitHub are maintained by same people 😉

[MichaIng]

Many thanks for your suggestion. So it's basically two separate things:

• Aligning the services working directory with the service users home directory to fix Git push. This is AFAIK the issue as the SSH connection lands in /home/dietpi while Gitrea stores the repos by default in /mnt/dietpi_userdata/gitea. Running Gitea as its own user gitea is a solution which makes sense anyway, and we should do the same with Gogs (where it is the same, AFAIK).
• Preparing everything for key authentication. Dropbear and OpenSSH both have it enabled by default, so the only required thing is the key pair and the ~/.ssh/authorized_keys entry. Again it makes sense for this to have Gitea running as its own user, to have Git client pushes done with an own set of key. The process of creating the key pair is not something we could or should automate: It should be created at the client and only the public key copied/installed on the server. This is something we can document. There is a simple OpenSSH client tool ssh-copy-id to automatically push the public key to the server, but it currently handles the Dropbear server falsely. Issue reported, sadly no answer from author/developer yet 😞: [ssh-copy-id] Do not treat Dropbear special openssh/openssh-portable#250

[LilTrublMakr]

The key pair is made on the client side and the public key is added to Gitea through the Gitea GUI. You can either make it repo specific (repo settings > deploy keys) or account wide (account settings > SSH/GPG keys). It works the exact same way as GitHub if you have ever used SSH access on that. As far as I know, no key pair was made on the server (in my case, RPi) side of things. But I am a complete novice on these things and trying to learn how everything works.

[MichaIng]

You can either make it repo specific (repo settings > deploy keys) or account wide (account settings > SSH/GPG keys).

Ah nice, I didn't know that. Makes it even easier and a good thing to add to our documentation 👍.

[LilTrublMakr]

So, I am not fully understanding what needs to be done. I am willing to work on this and to try and make a PR. (Again, new at all of this and trying to learn.)

On the forums, there is a post by @Joulinar that states:

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.

My understanding is that the general consensus on adding a new user (either git or gitea) is a good idea and should be implemented. But with that comes a security risk because /usr/bin/nologin is not set. Would the new user not only have access to just /mnt/dietpi_userdata/gitea?

Another thought I am wondering about is the different locations for the .ssh/authorized_keys file. Does it make sense to separate the Gitea and the system one? I have it set up this way in the way I got it to work because I could not get Gitea to be able to edit ~/.ssh/authorized_keys no matter who owned the file and no matter where I set the file location to in app.ini. I could be looking over something that might be completely simple. If that's the case, please let me know so I know for the future.

[MichaIng]

I'll postpone this for v7.6. I'll apply the same change to all Git servers we have, to get some consistency.

[MichaIng]

Sorry that it took a while. A PR is now up to apply this change: #5015
I recognised that we did this already for Gogs. I aligned both implementations as far as possible with each other. Needs testing whether it now works fine with the SSH key transfer and login.

I recognised that we set Environment=USER=dietpi HOME=/mnt/dietpi_userdata/gitea, hence may have forced the home directory to be where we want it. But probably the HOME variable was not respected for the SSH key copy feature or ssh-copy-id, but only the users real home directory. Also the services home directory somehow was set to the repository sub directory instead of that home/install parent directory.

Another thing I recognised is that we remove all repositories together when uninstalling Gitea. Not sure whether this is something we should preserve, to prevent data loss when users uninstall and reinstall Gitea in attempt to resolve issues or so? Gogs has it's repository directory at a dedicated place, and it is left there on uninstall, which sounds more reasonable.

[MichaIng]

Okay it seems to work fine now. Also public keys can be added to the interface, which was previously not possible if the OpenSSH client was not installed. This has now become a dependency.

@LilTrublMakr
Could you test it as well?

G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=dev' /boot/dietpi.txt
dietpi-update 1
dietpi-software reinstall 165

To revert to stable branch (and get the next update one v7.9 has been released at December 11th):

G_CONFIG_INJECT 'DEV_GITBRANCH=' 'DEV_GITBRANCH=master' /boot/dietpi.txt

[LilTrublMakr]

I will test this tomorrow.

I am thinking making a VM with the current image and setup Gitea and then run the commands above. Can I also simulate a new installation by running the commands above (but install instead of reinstall) with a fresh DietPi installation?

[MichaIng]

Can I also simulate a new installation by running the commands above (but install instead of reinstall) with a fresh DietPi installation?

Yes exactly, dietpi-software install 165 will then do it.