HOWTO (advanced) ssh transparent proxy jump

Jochen Bern
Mon, 21 Oct 2024 16:23:19 -0000

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>