Gitea with SSH

[j-zimnowoda]

Is your feature request related to a problem? Please describe. As a developer I would like to add my SSH public key to gitea, so I can work with git repo via SSH.

Describe the solution you'd like A clear and concise description of what you want to happen.

Define proxy for nginx-ingress controller https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

[MichaelTrip]

+1 for listening to potentional customers ;-)

[Ani1357]

• Enabled ssh in the gitea config file.
• Tried to create the needed resources as explained in the article but the nginx controller fails in reading the configMap
• The error may be caused by an incompatibility between the nginx-controller and the kubernetes version as showed in here. The version we are using supports k8s version up to 1.23
• Tested using version 1.3.0 but more errors appear.

[Ani1357]

• Tested upgrading the nginx-helm chart to version 4.3.0.
• The update was succesfull. Tested it by creating a service in otomi and exposing it to the public.
• Tried again to follow the official guide but the same issue as before. For some reason I get: Error getting ConfigMap "ingress/gitea-ssh": no object matching key "ingress/gitea-ssh" in local store
• Tried creating the configMap in other namespaces(default, istio-system) but still no success.
• Other issue: as soon as I add the new port(22) to the load balancer's configuration I can no longer access any url from the webui (otomi, drone, gitea, keycloak). .Although testing with netcat the right ports are open (80, 443, 22).

[merll]

Adding information from duplicate issue #1488:

When following the Otomi labs related to Gitea, it is not obvious how the repositories can be used locally (e.g. git clone). As the authentication is done via OpenID, it is not surprising that the Otomi credentials do not work when accessing the repo URL. However, it is not clear what the alternatives are.

It is possible to use Gitea as a remote using password authentication, by explicitly setting a Gitea password in the user profile. This however has two major drawbacks:

• It motivates insecure working practices. The user, out of convenience, may choose the same password as for Otomi, but the Git HTTP authentication does not provide good practices for handling secrets.
• In order to change the password, the user always needs to remember the old password; other reset-mechanisms do not seem to work. Users may forget that the Gitea password is not synchronized with the Otomi password, if they once set it identically.

There is one alternative to username/password authentication: Under (user) Settings -> Applications, the user can create an application token. Only access to repo is necessary. Then the user can clone and commit using the HTTP url https://[token]@gitea.mydomain.tld/[org]/[repo].git. This at least resolves issues connected to passwords above. Tokens can be removed if untrusted and regenerated as needed.

The web authentication in Gitea should nevertheless not be promoted for Git operations. SSH is also preferred on other platforms such as GitHub, as the private keys can be handled more securely (ssh-agent with Keychain access, MFA).