On 19.10.24 18:57, Maât wrote:
In a jump configuration HostA -> (HostB) -> HostC The classical way to connect is : usera@hosta $ *ssh -J userb@hostb userc@hostc* And to make it "locally transparent" I can use ProxyJump in .ssh/config : *HOST *hostc*ProxyJump *hostbIs 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@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@hostb/.ssh/authorized_keys - which implies that user@hosta still sees the host keys of host B, and authenticates themselves to host B, not host C. -- git@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@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@hostb by the Match block as appropriate.) Good luck, -- Jochen Bern Systemingenieur Binect GmbH
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
