Troubles SSHing to Gitea

LTM · 23 October 2022 01:03

Creating a bug report/issue

Required Information

DietPi version | 8.10.2
Distro version | bullseye 0
Kernel version | Linux DietPi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 GNU/Linux
SBC model | RPi 4 2GB
Power supply used | PoE w/ official V2 hat
SD card used | SanDisk ultra

Additional Information (if applicable)

Software title | Gitea
Was the software title installed freshly or updated/migrated? Fresh
Can this issue be replicated on a fresh installation of DietPi? Yes

Steps to reproduce

Install DietPi fresh.
Install Gitea + dependencies.
Setup Gitea using the guide on the Wiki
Create repo
Add SSH public key to repo
Try to git push from other machine.

Expected behavior

Git pushes to gitea

Actual behavior

The push is asking for a password for user Gitea

Extra details

I have had problems in the past getting SSH to work. I did a hacky solution that worked until I updated Gitea.
I have tried on both my old installation and a brand new installation.
I have tried both OpenSSH and Dropbear on new installations.
I have made sure that the keys were correctly installed in Gitea at both the repo and account level.
I have ran “Update the ‘.ssh/authorized_keys’ file with Gitea SSH keys.” in the server administration menu.
I am able to connect over SSH to the root user using a key pair
HTTP pushing does work as it should.

trendy · 23 October 2022 09:40

Have you created a pair of ssh keys in dietpi?
Have you uploaded the public key in gitea?
Have you configured gitea to know which keys to use to connect to gitea server?
Are the key file permissions correct?

LTM · 23 October 2022 11:27

Have you created a pair of ssh keys in dietpi?

Keys are generated automatically on installation of Dropbear/OpenSSH

Have you uploaded the public key in gitea?

Yes. I have tried uploading the public key at the repo level and account level making sure that all permissions are correct to be able to write to the repo.

Have you configured gitea to know which keys to use to connect to gitea server?

This is handled by Gitea. It should all be handled within Gitea through the GUI.

Are the key file permissions correct?

See last 2 answers.

trendy · 24 October 2022 09:10

Dropbear and OpenSSH are ssh servers, not ssh clients. Furthermore what they generate on installation are not ssh keys to be used to connect to other servers.
Have you installed openssh-client or some other client?
Have you created the keys with ssh-keygen ?

LTM · 24 October 2022 11:33

I understand how key pairs work. But I will outline what I have done:

Generated a key pair using ssh-keygen -t ed25519 -C "comment"
I used cat ed25519.pub to obtain the public key.
I took the public key and put it both at the repo level (Gitea → Repo → Settings → Deploy Keys) and at the account level (Gitea → Account → Settings → SSH / GPG Keys)
Tried to push via SSH and it asks for a password

I used the Github’s version of the same thing using the same keys (again, both at the repo and account level) and it is working as it should.

It is not the keys. It is something with how Gitea is set up on DietPi. Again, fresh installation and all I did was install Gitea and its dependencies. I tried with both Dropbear and Open SSH on fresh installations.

EDIT: I have also made sure that the SSH config files are correct on the client side. The authorized_hosts on the DietPi side is also generated by Gitea located in /mnt/dietpi_userdata/gitea/.ssh.

trendy · 24 October 2022 12:14

Can you try with -t rsa ?
Also are you certain that the client is using the correct private key?

LTM · 24 October 2022 12:29

I have tried with RSA 2048 and 4096 with the same outcome.

I am 110% positive that I am using the correct key since it is the only key pair on that client I am testing on. Again, I have used the same key pair to test with Github, and it is working as it should.

trendy · 24 October 2022 13:33

Alright, I’ll try to reproduce it.

Joulinar · 24 October 2022 13:57

There is nothing special on our install procedure. We download lates archive from GitHub, move it into /mnt/dietpi_userdata/gitea/gitea, create user + databse + service and change ownership of files to gitea. That’s it. Nothing else we do.

github.com

MichaIng/DietPi/blob/master/dietpi/dietpi-software#L11384-L11434


      
          				dps_index=$software_id Download_Install "nginx.tasmoadmin$version.conf" "$tasmoadmin_conf"
          			fi
          
          			# Enable required PHP modules
          			G_EXEC phpenmod "${adeps[@]}"
          		fi
          
          		if To_Install 206 openhab # openHAB
          		then
          			# APT key
          			local url='https://openhab.jfrog.io/artifactory/api/gpg/key/public'
          			G_CHECK_URL "$url"
          			G_EXEC eval "curl -sSfL '$url' | gpg --dearmor -o /etc/apt/trusted.gpg.d/dietpi-openhab.gpg --yes"
          
          			# APT list
          			# - Enable RISC-V support by explicitly defining arch=all, which contains exactly the same packages (well, it's Java...)
          			local arch=
          			(( $G_HW_ARCH == 11 )) && arch=' [arch=all]'
          			G_EXEC eval "echo 'deb$arch https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable main' > /etc/apt/sources.list.d/dietpi-openhab.list"
          			G_AGUP

This file has been truncated. show original

LTM · 24 October 2022 15:27

I’m interested in knowing if it’s just me or if it’s happening for others as well. I don’t get why it is failing the key pair.

I’ll do some more testing tonight and try it on Gogs.

trendy · 24 October 2022 17:11

The problem is in gitea.
From the logs:

Οκτ 24 19:01:28 raspi dropbear[702485]: Bad public key options at /mnt/dietpi_userdata/gitea/.ssh/authorized_keys:2

And if you see what is in there:

gitea@raspi:~$ cat .ssh/authorized_keys 
# gitea public key
command="/mnt/dietpi_userdata/gitea/gitea --config=/mnt/dietpi_userdata/gitea/custom/conf/app.ini serv key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,no-user-rc,restrict ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC6c/QrHmtG6XFwZTJVaYYNT5DbKTlC3yL3Z0SeXvcCvO0nXy7Jwck97rm1To2yzpO8q+DOXfPKGoTSy7WW9lQLf4v0fEBO7Wh34T+jkMl04Nn6dyaDs8fxU9T1wmWuz+wQx5D+0ACAQhTrzR7LSlREPviZu4fbOkaL7TDvFFggbVTZoIeOdd/6qd3s4od0Y4RnI7DHr4foCdByXdOFnxSX4YL2E ....

I am not sure if this can work with OpenSSHd, but certainly Dropbear doesn’t like it.

Joulinar · 24 October 2022 17:35

Any hin on the logs which of the options is bad one?

LTM · 24 October 2022 17:47

The only log for OpenSSH using journalctl -u ssh is:

Oct 24 13:44:38 DietPi sshd[345076]: Connection closed by authenticating user gitea 192.168.0.169 port 36408 [preauth]

trendy · 24 October 2022 22:43

There are some FAQs in gitea site to troubleshoot further:

LTM · 25 October 2022 01:10

Trying to SSH directly is still asking for a password.

The key is definitely getting refused for whatever reason.

➜  .ssh git:(master) ✗ ssh -i /config/.ssh/privateGitea -F /dev/null git@github.com
PTY allocation request failed on channel 0
Hi LilTrublMakr/home-assistant! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.
➜  .ssh git:(master) ✗ ssh -i /config/.ssh/privateGitea -F /dev/null gitea@gitea.sudo
gitea@gitea.sudo's password:

Logs of ssh -i /config/.ssh/privateGitea -F /dev/null gitea@gitea.sudo -vvv:

debug1: Next authentication method: publickey
debug1: Offering public key: /config/.ssh/privateGitea ED25519 SHA256:8x...to explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51

Packet type 51 = SSH_MSG_USERAUTH_FAILURE

I am at a loss here. I have tried everything I can think of and

trendy · 25 October 2022 06:58

I think you are troubleshooting in vain. The extra commands that gitea adds in the authorized_keys file don’t seem to be compatible, at least with Dropbear. Try to remove the first part until the ssh-rsa starts and see if that will work.

Joulinar · 25 October 2022 08:39

I tend to agree with @trendy . Would be good to test without all the Gitea options added into key file.

LTM · 26 October 2022 01:59

I removed all options, same deal. I think at this point, I am going to just run it as a Docker container and use the internal SSH server. I don’t understand what has changed, but I am not getting anywhere with figuring out what is going on.

LTM · 5 November 2022 03:39

Well, through a ton of trial and error, I got it to work again.

The thing for DietPi is that the Gitea user needs shell access. I had to change /usr/sbin/nologin to /bin/bash in /etc/passwd. I know its far from ideal from a security standpoint, but that is what needs to be changed for it to work out of the box.

I also had to change the SSH command in the git repository to include the key file: git config core.sshCommand 'ssh -i ./.ssh/private_key_file'

I am not sure why it is not respecting the git configuration file, but for now it is working.

Joulinar · 6 November 2022 19:44

Yes, usually all application users are created in a way not being able to login.