Right, there's an interesting split in modernizing/hardening SSH philosophies:
Philosophy 1: Move to hardware SSH keys. That's what Y4s and Nitrokeys represent: keys where, if your machine is compromised, the SSH key itself can't easily be stolen.
Philosophy 2: Move to SSH CAs that issue short-lived certificates, and use U2F to authenticate issuance. This is roughly how you'd do a modern integration of an SSO system (like Okta or GSuite) with your SSH services.
SSH CAs have more steam behind them, and are desirable for a bunch of reasons that hardware SSH keys don't really address.
Since the primary function (beyond U2F, which these keys don't do) of a hardware key is to protect your SSH key, I guess it's worth considering how they fit into the modern SSH worldview or whatever you want to call it.
Isn't using U2F+SSH CA's just moving the challenge-response protocol one level up?
U2F is "just" a hardware P-256 key (or a set of keys unique to origin, but ignoring privacy issues they are comparable, of course I'm assuming the same setup so touch-to-use set to required).
(I've set up SSH CAs manually and I'm familiar with low level U2F for that matter).
Philosophy 1: Move to hardware SSH keys. That's what Y4s and Nitrokeys represent: keys where, if your machine is compromised, the SSH key itself can't easily be stolen.
Philosophy 2: Move to SSH CAs that issue short-lived certificates, and use U2F to authenticate issuance. This is roughly how you'd do a modern integration of an SSO system (like Okta or GSuite) with your SSH services.
SSH CAs have more steam behind them, and are desirable for a bunch of reasons that hardware SSH keys don't really address.
Since the primary function (beyond U2F, which these keys don't do) of a hardware key is to protect your SSH key, I guess it's worth considering how they fit into the modern SSH worldview or whatever you want to call it.