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?
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.
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 ?
1 Like
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.pubto 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.
Can you try with -t rsa ?
Also are you certain that the client is using the correct private key?
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.
Alright, I’ll try to reproduce it.
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.
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.
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.
Any hin on the logs which of the options is bad one?
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]
There are some FAQs in gitea site to troubleshoot further:
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
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.
I tend to agree with @trendy . Would be good to test without all the Gitea options added into key file.
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.
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.
3 Likes
Yes, usually all application users are created in a way not being able to login.
Not a very useful comment but I ran into the same issue and this fixed it. Thanks!