When adding keys, constrain them to be usable only through specific hosts or to specific destinations.
Destination constraints of the form ‘[user@]dest-hostname’ permit use of the key only from the origin host (the one running ssh-agent(1)) to the listed destination host, with optional user name.
Constraints of the form ‘src-hostname>[user@]dst-hostname’ allow a key available on a forwarded ssh-agent(1) to be used through a particular host (as specified by ‘src-hostname’) to authenticate to a further host, specified by ‘dst-hostname’.
Multiple destination constraints may be added when loading keys. When attempting authentication with a key that has destination constraints, the whole connection path, including ssh-agent(1) forwarding, is tested against those constraints and each hop must be permitted for the attempt to succeed. For example, if key is forwarded to a remote host, ‘host-b’, and is attempting authentication to another host, ‘host-c’, then the operation will be successful only if ‘host-b’ was permitted from the origin host and the subsequent ‘host-b>host-c’ hop is also permitted by destination constraints.
Hosts are identified by their host keys, and are looked up from known hosts files by ssh-add. Wildcards patterns may be used for hostnames and certificate host keys are supported. By default, keys added by ssh-add are not destination constrained.
Destination constraints were added in OpenSSH release 8.9. Support in both the remote SSH client and server is required when using destination-constrained keys over a forwarded ssh-agent(1) channel.
It is also important to note that destination constraints can only be enforced by ssh-agent(1) when a key is used, or when it is forwarded by a cooperating ssh(1). Specifically, it does not prevent an attacker with access to a remote SSH_AUTH_SOCK from forwarding it again and using it on a different host (but only to a permitted destination).