openssh unix dev - Oct 2024 - HOWTO (advanced) ssh transparent proxy jump

Hello OpenSSH team,

(New subscriber and very first message... by the way thanks for bringing 
ssh to the wolrd).

I have a question, maybe not so simple.

_The question in short :
_

Context? :_
_

    In a jump configuration HostA -> (HostB) -> HostC

    The classical way to connect is :

        usera at hosta $ *ssh -J userb at hostb userc at hostc*

    And to make it "locally transparent" I can use ProxyJump in
    .ssh/config :

        *HOST *hostc*ProxyJump *hostb

    (I can even use ProxyCommand if i want to make things more
    complicated or if ssh version does not allow ProxyJump)

    Then? i can just connect to hostC with :

        ssh *userc at hostc*

The question :

Is there a way to achieve the same "simplification" but with a setting
on hostb instead of hosta ?

(The goal is to avoid asking users to make such local configuration)

I'd imagine something like a command in .ssh/authorized_keys of userb :

    command="/usr/bin/ssh --magic --proxyjumpto userc at hostc"
ssh-ed25519
    AAAAblahblahblahblahthekeyofusera

(And ideally i'd forward blindly without checking the key as hostc will 
do the real check)


===
Long version and real case :

I'm willing to replace an old git infrastructure (local gitolite) with a 
brand new gitlab... in a container.

hosta would be the computer of a contributor, hostb would be the machine 
hosting the container, hostc would be the gitlab container itself.

The ports i have open currently for the host machine are 80, 443 and 
22... perfect for gitlab and standard and everything... but if both 
gitlab in the docker and sshd on the host need port 22 i have a problem...

If I map port 22:22 for the gitlab container that would need me to 
change the port for sshd to something higher (and i'd rather avoid 
it)... if i map the gitlab port like 22:2022 it would require 
contributors to use an exotic port which might annoy them or even be 
blocked for some of them.

Both options are annoying.

So i'm searching a tricky way to keep port 22 for both and forward 
transparently ssh to git at thegitlabcontainer only for users connecting to 
the host (with git user) git at mynewgit.mycommunity.org

===
I checked the documentation, made tries with -W... without success

I asked to Linux gurus around me without success... they've never seen 
this case. So in last resort I escalate to higher level : the source of 
openssh project = you guys :)

With high hopes,

Ma?t

(PS : sorry list owners for polluting your mail box i did sent it to 
-owner at list address first... and with html shame on me)

On Oct 19, 2024, at 10:03, Ma?t via openssh-unix-dev <openssh-unix-dev at
mindrot.org> wrote:
> ?[...]
> Long version and real case :
> [...]
> hosta would be the computer of a contributor, hostb would be the machine
hosting the container, hostc would be the gitlab container itself.
> 
> If I map port 22:22 for the gitlab container that would need me to change
the port for sshd to something higher (and i'd rather avoid it)
Why avoid it? What use cases are there for logging into host b, besides as a
jump host?

-- 
jim knoble

On 19.10.24 18:57, Ma?t wrote:
>  ?? In a jump configuration HostA -> (HostB) -> HostC
>  ?? The classical way to connect is :
>  ?????? usera at hosta $ *ssh -J userb at hostb userc at hostc*
>  ?? And to make it "locally transparent" I can use ProxyJump in
>  ?? .ssh/config :
>  ?????? *HOST *hostc*ProxyJump *hostb
> Is there a way to achieve the same "simplification" but with a
setting
> on hostb instead of hosta ?
In the general case, an entirely uninformed ssh(1) Client on host A will 
not be willing to do remote-host- and local-user-auth *twice*. I can 
barely imagine an evil kludge to get around that for the user auth, *if* 
you're willing to write a special sshd(8) version for host B yourself, 
but no idea for the host auth.

Still, I think that it might be barely doable in *your* specific case. 
Let me summarize the relevant prerequisites, just to be clear:
-- All special-treatment (first-hop) SSH sessions go to a single user
    git at hostb, and *all* logins to it are to be treated that way
-- Host C is a container on host B, and thus already has to place a lot
    of trust into host B; in particular, it is reasonable to assume that
    the communication between B and C is quite MitM proof

What I would try is the following:
-- Management of allowed users is still done by
    ~git at hostb/.ssh/authorized_keys - which implies that user at hosta still
    sees the host keys of host B, and authenticates themselves to host B,
    not host C.
-- git at hostb and git(?)@hostc get user keypairs, known_hosts,
    authorized_keys etc. etc. prepared by the sysadmin (you) so as to do
    a password- and intervening-output-less login from the former to the
    latter. Extra points if these users can NOT modify those files
    themselves. (Monitor them nonetheless.)
-- Instead of giving every user pubkey a command="..." option in
    git at hostb's authorized_keys, do a "Match user git" in host
B's
    /etc/ssh/sshd_config to give that account a ForceCommand.
-- I presume that you might see both "interactive" and single-command
    logins. That means that the ForceCommand needs to be a wrapper that
    checks for $SSH_ORIGINAL_COMMAND, and adds that to the ssh(1) to host
    C if found - possibly doing some changes to further ssh(1) options as
    well.
-- The exact ssh(1) command to be used by the wrapper and the
    preparation for the same are probably up to a fair bit of trial and
    error - think "-t", massaging $TERM, ...
-- (Note that doing any kind of *forwarding* in such a setting would get
    very complicated at best, and a backdoor into host B at worst.
    Further restrict git at hostb by the Match block as appropriate.)

Good luck,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4160 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20241021/be9ad0a9/attachment.p7s>