That won't work. You will need to use full disk encryption. Otherwise, I can just plug your HD into another computer and have full access to your files. Several Linux distros support this. Windows sort of supports it, but it sucks and can be cracked.
Discussion
That's great, because you can direct unlimited resources to physically secure the hardware. But what I really want is to physically secure the remote side by making it just as physically costly to obtain the signing keys as well.
So what I'm wondering is if there's any issue with the only two pieces of information on the wire to be a random message to the client and the signed random message to the server in order to establish an ssh connection.
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.
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.