Config SSH via Nginx Ingress & MetalLB, helm install (Again) #700

New Issue

2024-08-21T14:20:04Z

marcelodsales commented

2024-08-21 14:20:04 +00:00

(Migrated from gitea.com)

I read that there is already an old issue for this but as it is already closed I decided to open another one.

I don't think it's a defect or problem, I'd say it's much more an adjustment to the documentation or creation of a new one, if applicable.

I propose to help with writing, as long as I can make it work.

My problem is getting a connection via SSH using ingress nginx.

gitea is working on my cluster over HTTPS. However, I can't get the clone to work via ssh.

Every time I try to clone I am forced to provide a password, even though I have already copied the id_rsa.pub to the gitea server. And no matter what password I provide, none of it seems valid.

It takes me a day to follow various guidelines, tutorials, and recommendations from the most varied forums. Following the documentation here, apparently, I'm just guided to do this here:

service: ssh: annotations: metallb.universe.tf/allow-shared-ip: test

`
...

debug1: Reading configuration data /home/USER/.ssh/config
debug1: /home/USER/.ssh/config line 1: Applying options for gitea-ssh.DOMAIN
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug3: expanded UserKnownHostsFile '/.ssh/known_hosts' -> '/home/USER/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '/.ssh/known_hosts2' -> '/home/USER/.ssh/known_hosts2'
debug2: resolving "gitea-ssh.DOMAIN" port 22
debug3: resolve_host: lookup gitea-ssh.DOMAIN:22
debug3: ssh_connect_direct: entering
debug1: Connecting to gitea-ssh.DOMAIN [IP] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/USER/.ssh/id_rsa_gitea type 0
debug1: identity file /home/USER/.ssh/id_rsa_gitea-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Debian-2+deb12u3
debug1: compat_banner: match: OpenSSH_9.2p1 Debian-2+deb12u3 pat OpenSSH compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to gitea-ssh.DOMAIN:22 as 'git'

...
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/USER/.ssh/id_rsa_gitea RSA SHA256:y43kNhCRPYnFwSO4RW3Sy02B+WaDW4To4EZ95uBAmZs explicit agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
`

I read that there is already an old issue for this but as it is already closed I decided to open another one. I don't think it's a defect or problem, I'd say it's much more an adjustment to the documentation or creation of a new one, if applicable. I propose to help with writing, as long as I can make it work. My problem is getting a connection via SSH using ingress nginx. gitea is working on my cluster over HTTPS. However, I can't get the clone to work via ssh. Every time I try to clone I am forced to provide a password, even though I have already copied the id_rsa.pub to the gitea server. And no matter what password I provide, none of it seems valid. It takes me a day to follow various guidelines, tutorials, and recommendations from the most varied forums. Following the documentation here, apparently, I'm just guided to do this here: `service: ssh: annotations: metallb.universe.tf/allow-shared-ip: test` ` ... debug1: Reading configuration data /home/USER/.ssh/config debug1: /home/USER/.ssh/config line 1: Applying options for gitea-ssh.DOMAIN debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files debug1: /etc/ssh/ssh_config line 21: Applying options for * debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/USER/.ssh/known_hosts' debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/USER/.ssh/known_hosts2' debug2: resolving "gitea-ssh.DOMAIN" port 22 debug3: resolve_host: lookup gitea-ssh.DOMAIN:22 debug3: ssh_connect_direct: entering debug1: Connecting to gitea-ssh.DOMAIN [IP] port 22. debug3: set_sock_tos: set socket 3 IP_TOS 0x10 debug1: Connection established. debug1: identity file /home/USER/.ssh/id_rsa_gitea type 0 debug1: identity file /home/USER/.ssh/id_rsa_gitea-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Debian-2+deb12u3 debug1: compat_banner: match: OpenSSH_9.2p1 Debian-2+deb12u3 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to gitea-ssh.DOMAIN:22 as 'git' ... debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/USER/.ssh/id_rsa_gitea RSA SHA256:y43kNhCRPYnFwSO4RW3Sy02B+WaDW4To4EZ95uBAmZs explicit agent debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password `

pat-s commented

2024-09-02 08:30:16 +00:00

(Migrated from gitea.com)

I agree the documentation is not fully clear about this.
The setting is just an example and won't work by just c/p.

What you need is:

A dedicated service for SSH (enable in values.yml)
This service should share the (loadbalancer) IP with other services, in this case the https service for gitea
Both services (the ssh and the https one in Gitea) need to have this annotation set
In addition you need to make sure that SSH is not running on port 22 on your nodes as it will conflict with the Gitea service. To circumvent this, you can move SSH on the nodes to a different port or choose another port for the Gitea service.

See https://metallb.universe.tf/usage/#ip-address-sharing for more information about the Metallb setting.

Do you have Metallb running in your cluster? Or any other LB? As mentioned, ingress can't do the forwarding and you need your LB to point to the SSH service. The mentioned setting however only applies to Metallb.

I've wanted to update the documentation a few times in the past already but always forgot about it.

I agree the documentation is not fully clear about this. The setting is just an example and won't work by just c/p. What you need is: - A dedicated service for SSH (enable in `values.yml`) - This service should share the (loadbalancer) IP with other services, in this case the https service for gitea - Both services (the ssh and the https one in Gitea) need to have this annotation set - In addition you need to make sure that SSH is not running on port 22 on your nodes as it will conflict with the Gitea service. To circumvent this, you can move SSH on the nodes to a different port or choose another port for the Gitea service. See https://metallb.universe.tf/usage/#ip-address-sharing for more information about the Metallb setting. Do you have Metallb running in your cluster? Or any other LB? As mentioned, ingress can't do the forwarding and you need your LB to point to the SSH service. The mentioned setting however only applies to Metallb. I've wanted to update the documentation a few times in the past already but always forgot about it.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lunny/helm-chart#700