Can't authenticate to Gitea using SSH

Troubleshooting
1

Required Information

  • DietPi version | 8.11.2
  • Distro version | buster
  • Kernel version | Linux DietPi 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux
  • SBC model | RPi4
  • Power supply used | Official 5A supply
  • SD card used | Sandisk ultra

Additional Information (if applicable)

  • Software title | gitea
  • Was the software title installed freshly or updated/migrated? New Install
  • Can this issue be replicated on a fresh installation of DietPi? Unsure

Steps to reproduce

Install Gitea.
Add a user & their SSH key.
Create a repo.
Add it as an SSH remote to a client.
Attempt to push.

Actual behaviour

Cannot push/pull to repos via Gitea if authenticating using SSH.
The client insists on asking for a password to the remote host. No password works and the server (dropbear) logs a User account 'gitea' is locked each time I make an attempt.

Extra details

HTTP auth works fine.
The keypair works on Github so I trust that is working fine. I also use the same keypair when SSHing into the RPi itself, with no apparent issues.
Multiple clients with different keys hit the same problem.
At first I thought it was because I had routed Gitea through an NGINX reverse proxy, but even after removing that, I have the same issue.
My symptoms sound the same as Troubles SSHing to Gitea, but I don’t get the same error from Dropbear (just the account locked message), or any other errors from Gitea. I tried giving gitea shell access anyway, but it didn’t help.

2

did you adjust the user gitea as described on the other post? Troubles SSHing to Gitea - #19 by LTM

By default the user has no login possibility.

3

OK, it turned out to be a couple issues from the combo of Gitea and Dropbear on Dietpi:

  1. The dropbear version shipped with dietpi is quite old, and doesn’t support the fairly standard ed25519 keytype. RSA keys also didn’t work because they are disabled on most clients. I had to override the clients to allow +ssh-rsa, which isn’t secure, but is fine on my local only install. I’d recommend updating the Dropbear shipped in Dietpi to a version that can handle more recent SSH key types.

  2. As hinted at in the other thread, Gitea adds arguments in authorized_keys that Dropbear doesn’t support. Gitea will have to fix this long term (restrict and no-user-rc in authorized_keys cause error in dropbear(openwrt). · Issue #21383 · go-gitea/gitea · GitHub), but in the meantime I could manually edit the authorized_keys file to remove them

  3. I had already tried it, but verified that the Gitea user needs shell access as described in the other thread. It would be great if this wasn’t necessary but I don’t know enough about how Gitea works to tighten it up otherwise.

4

DietPi don’t have an own repository. We use global Debian apt repository. Means, version of Dropbear depends on your Debian version Debian -- Package Search Results -- Dropbear

A newer version would be available on Debian Bullseye. There you would need to upgrade your system. Just have a look to our upgrade guide DietPi - How to upgrade to "Bullseye" - DietPi blog

2 Likes