restrict and no-user-rc in authorized_keys cause error in dropbear(openwrt).

[mokeyish]

Description

I can't use git clone git@xxxx in openwrt after PR #17772. It would be ok after I delete no-user-rc,restrict manully.

The error output

---

✘ root@Me  ~/abc  git clone git@xxxx:yyy/abc.git
Cloning into 'abc'...
git@xxxx: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights

---

The system log

Sun Oct  9 11:12:51 2022 authpriv.info dropbear[16361]: Child connection from 10.10.0.10:51874
Sun Oct  9 11:12:51 2022 authpriv.warn dropbear[16361]: Port forwarding disabled.
Sun Oct  9 11:12:51 2022 authpriv.warn dropbear[16361]: Agent forwarding disabled.
Sun Oct  9 11:12:51 2022 authpriv.warn dropbear[16361]: Pty allocation disabled.
Sun Oct  9 11:12:51 2022 authpriv.warn dropbear[16361]: Bad public key options at /home/git/.ssh/authorized_keys:2
Sun Oct  9 11:12:51 2022 authpriv.info dropbear[16361]: Exit before auth from <10.10.0.10:51874>: (user 'git', 0 fails): Exited normally
Sun Oct  9 11:12:52 2022 authpriv.info dropbear[16362]: Child connection from 10.10.0.10:51877

Gitea Version

After PR #17772

Screenshots

Dropbear version:

Git Version

2.34.3

Operating System

OpenWrt(22). x86-64

[mokeyish]

@zacheryph @techknowlogick @mscherer
Hi, Is there a way to change the sshpublickey template? dropbear not support restrict and no-user-rc

[zeripath]

We did not expect that anyone would want/need to change these options.

The likely problem is related to the version of the SSH in openWRT.

Now... we could make this configurable

[mokeyish]

Since it's hard to find the probelm when throw error like Permission denied (publickey)., so

Maybe we can detect automaticlly. if port 22 is listened by dropbear, then ignore restrict and no-user-rc

[shionphan]

@mokeyish Thanks a lot, i have the same issue. git clone work after I delete no-user-rc,restrict manully.

Gitea 1.17.3 on Synology NAS (no docker)

[fomojola]

@mokeyish Echoing this issue: running on an old Ubuntu version, upgraded from 1.15.4 to 1.17.4 and this error occurred. Manually went in and removed the ,restrict text and restored full working functionality.

Looking at the release logs, this functionality appears to have been added in 1.16.0. Looking at the OpenSSH release notes from https://www.openssh.com/releasenotes.html, it appears that support for the restrict authorized_keys flag was added in OpenSSH 7.1p2. The specific template that controls those lines appears to be at https://github.com/go-gitea/gitea/blob/main/models/asymkey/ssh_key_authorized_keys.go#L42

I've never made any changes to the gitea source, so wasn't sure if there is existing support for passing in one of those templates as a configuration or environmental variable, but support for overriding that template would be extremely helpful for systems running earlier OpenSSH versions, or a prominent note in the release logs that upgrades to OpenSSH will be required for future releases.

Thanks!

[Tlepel]

Thanks for making this issue, I've been looking through gitea logs, git logs, ssh logs and openbear logs before I found out what the issue was.
I don't really want to switch over to openssh to fix this issue on my side, so hopefully it'll be changed or adapted in gitea soon :)

[mokeyish]

It's a bit troublesome,I have to manually delete those two items every time gitea upgrade.