Good news. This works great and you already have the software necessary to do it: ssh. It supports signing in with a key instead of a password. Not sure if it works with Bitcoin keys, but it's better to use a separate key anyway. You don't want a compromise of your server to also cost you your life savings.
Discussion
An ssh private key is still on the remote machine, but only readable by your user.
What I want is for that key to be airgapped. And multisig. And everything else you can do to secure, say, a Bitcoin key that only has access to a 1000 sat utxo on chain, but that utxo buys you access to a server. To make it physically impossible to steal or spoof that key.
That's the normal way of doing things, but it's not the only way. The key is only needed for connection setup. After that, a newly generated 'session key' is used for communication. You could create a custom client that used external keys for authentication. There is probably already an ssh client that can use an external signing device, but I would be surprised if an airgapped version exists. I don't know how complicated the protocol setup is, but I would guess it takes more than two steps.
Anyway, since you are opening an on-going control connection, an attacker only has to hijack your computer to gain access. Air gaps don't really gain you anything in this case. Bitcoin is much more limited in the scope of what needs to be signed, so it's much easier to air gap.
say again? why is the private key on a remote?
Sorry I was talking from the server's perspective, accepting connections from remote clients.
Still not sure if I understand the flow.
It's probably easiest to write a pam plugin.
That's my plan actually. The plugin hooks into the password flow, sends a challenge token and, expects the signed message back, and authorizes the connection. A talk with AI gave me the configuration code and steps, I just need to do it on a VM and see if it works.