Le 19/10/2024 à 21:59, Jim Knoble a écrit :
[Added openssh-unix-dev@ back to thread].
On Oct 19, 2024, at 12:02, Maât <maat-ml@xxxxxxxxxx> wrote:
Le 19/10/2024 à 19:32, Jim Knoble a écrit :
Why avoid it? What use cases are there for logging into host b, besides as a jump host?
In fact this "B" machine has several roles, [which get enumerated...]
Have you considered assigning a different IP (or IPv6) address to the name assigned to the exposed GitLab? Then it's a different listening host:port and requires no additional proxy jumping.
Another option is to forbid SSH access to the GitLab instance altogether and require HTTPS access only, which handles virtual hosts nicely. (This could also reduce the attack surface against GitLab).
--
jim knoble
(thanks for adding back the list)
The IPs are given to us by a sponsor provider... I'd rather not ask for
one more given that these are becoming rare and precious.
The other solution is already planned : gitlab will be available on
https/443 (http/80 will redirect to 443) but gitlab read/write tokens
are not recommended, typing the password at each git pull / git fetch /
git push would make contributors lives a hell... and enabling temporary
(or worse : permanent) password memorization by git is a very bad practice.
Using ssh and ssh-agent is far better for security and contributors
comfort... which brings me back to annoying contributors with a port
change or find a "magic ssh solution".
Kind regards,
Maât
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
