Mailing List Archive

Match Principal enhancement
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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Match Principal enhancement [ In reply to ]
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@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Match Principal enhancement [ In reply to ]
Ah - many thanks. It doesn’t matter how many times I read the manual, it seems there is always something new to learn.

Cheers,

Bret

On 12 Nov 2023, at 22:35, Damien Miller <djm@mindrot.org> wrote:

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev