AFAIK everything you described here could be done using the
AuthorizedKeysCommand or AuthorizedPrincipalsCommand directives. These
can emit authorized_keys options (inc. permitopen) as well as the allowed
keys/principals.
On Sun, 12 Nov 2023, Bret Giddings wrote:
> Hi OpenSSH devs,
>
> I?m wondering if the following has any merit and can be done securely ...
>
> If you could match on principals in the sshd_config, then (for example) on
a gateway machine, you could have something like
>
> /etc/ssh/authorized_keys/sshfwd:
>
> cert-authority,principals=?batcha-fwd,batchb-fwd? ...
>
> /etc/ssh/sshd_config containing:
>
> Match User sshfwd
> PubkeyAuthentication yes
> PasswordAuthentication no
> GatewayPorts no
> AllowTcpForwarding yes
> HostbasedAuthentication no
> AllowAgentForwarding no
> X11Forwarding no
> Banner none
> ForceCommand /bin/false
> AuthorizedKeysFile /etc/ssh/authorized_keys/%u
>
> Match Principal batcha-fwd
> PermitOpen 10.0.0.1:22
>
> Match Principal batcha-fwd
> PermitOpen 10.0.0.2:22
>
> This would mean that on the ssh gateway machine, you don?t need an account
for every remote batch account that needs to connect, assuming that a signed key
has previously been provided with appropriate principals (and maybe
source-addresses etc). They would be configured to use something like the
following in their ssh config file
>
> Host sshgw.example.com <http://sshgw.example.com/>
> User sshfwd
> ProxyJump none
>
> Host *.example.com
> IdentitiesOnly yes
> IdentityFile batcha
> User batcha
> ProxyJump batcha
>
> I can also see other potential uses for it on target computers where I only
allow connections using keys signed by a trusted CA.
>
> Regards,
>
> Bret
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>