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@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
