HOWTO (advanced) ssh transparent proxy jump

[Jochen Bern]

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>