The server can have restrictions on where SSH keys are valid from. Furthermore the server side public SSH keys can be moved under /etc/ssh/keys so they are harder to tamper with vs a users .ssh dir in $HOME. This can significantly reduce the blast radius of a leaked key. Furthermore the server side file should be set immutable and read-only and something like Tripwire or OSSEC should be monitoring for changes to anything in /etc. Additionally one can limit access to SSH over a VPN such as Wireguard unless this is a public SFTP server.

    # grep "/etc/ssh/keys/" /etc/ssh/sshd_config
    AuthorizedKeysFile /etc/ssh/keys/%u

    # chmod 0444 /etc/ssh/keys/root
    # chattr +i /etc/ssh/keys/root

    # cat /etc/ssh/keys/root
    from="172.16.0.0/12,26.10.15.0/24" ssh-ed25519 AAAA...[snip].... JIRA-10040

Likely, sufficiently complex passwords will continue to be the frontline defense.

I also think SSH certificate authentication mostly solves the “key comes from anywhere” problem by automatically expiring certificates.

This isn’t as immune to this type of attack as Secure Enclave, but you do get a benefit where the user has to get the correct certificate periodically in order to maintain access.

If I pass my credentials and certificates to someone else or someone steals them, they’ll eventually expire them, or I can expire them if I know a breach has occurred.

The impracticalities of Secure Enclave are obvious to all of us: recent Apple devices only.