Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add openssh-keygen to Dockerfile-rootless #33783

Open
p7kdev opened this issue Mar 4, 2025 · 2 comments · May be fixed by #33974
Open

Please add openssh-keygen to Dockerfile-rootless #33783

p7kdev opened this issue Mar 4, 2025 · 2 comments · May be fixed by #33974
Labels
topic/build PR changes how Gitea is built, i.e. regarding Docker or the Makefile type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@p7kdev
Copy link

p7kdev commented Mar 4, 2025

Feature Description

Hi,

I prefer the rootless container variant and use the built-in SSH server. This works perfectly so far. I only have the problem of the initial installation and the generation of the SSH host keys, because there is no tool in the rootless image to generate the keys. I am aware that an RSA key is created automatically. But the others (ecdsa, ed25519) are not.

I run this in K8s. At the moment I'm helping myself by having an initContainer (the rootfull variant), which then generates the keys with openssh-keygen. But that feels like overkill to define an extra image just for that instead of using the same rootless image. It would be much more convenient if the openssh-keygen tool was also available in the rootless container. It only adds a few KB, but really makes your life easier.

af2800d5c2df:/var/lib/gitea# apk add openssh-keygen -i
The following NEW packages will be installed:
  openssh-keygen
Need to download 202 KiB of packages.
After this operation, 470 KiB of additional disk space will be used.

The official helm chart uses the rootfull variant by default. There is also a flag to use the rootless variant. In this case, however, only the RSA key seems to be created and used. That feels incomplete.

Thanks already!

Best regards,
Paul

Screenshots

No response

@p7kdev p7kdev added the type/proposal The new feature has not been accepted yet but needs to be discussed first. label Mar 4, 2025
@kemzeb kemzeb added the topic/build PR changes how Gitea is built, i.e. regarding Docker or the Makefile label Mar 4, 2025
@TheFox0x7 TheFox0x7 linked a pull request Mar 22, 2025 that will close this issue
@TheFox0x7
Copy link
Contributor

Would parity of generating rsa, ecdsa and ed25519 keys be enough, or do you want openssh-keygen to be included as well?

@p7kdev
Copy link
Author

p7kdev commented Mar 23, 2025

Thank you very much!

If all keys could be created automatically, this would certainly be welcome and would provide a better out of the box experience for all (rootless) users. It would also reflect the same behavior that the rootfull container has (openssh also generates all keys automatically, if not already present)!

However, it would be useful to have the option of creating keys yourself. Simply to generate new keys or to define the properties of the keys (e.g. the keysize of the RSA key). openssh-keygen was just the most obvious solution. But if gitea itself has the ability to create keys, we could also extend the CLI so that we can do that with it. There is already a generate command that can create secrets. It would be logical to use it to create SSH keys as well. Or alternatively a gitea genkey command. That would of course be much better than being dependent on openssh-keygen.

gitea generate --help
NAME:
   gitea generate - Generate Gitea's secrets/keys/tokens

USAGE:
   gitea generate command [command options]

COMMANDS:
   secret   Generate a secret token
   help, h  Shows a list of commands or help for one command

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/build PR changes how Gitea is built, i.e. regarding Docker or the Makefile type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants