4 ms·

No, and expecting users to actually do so is a sign that something is very wrong about the process. TOFU turns out to be good enough for most purposes anyway,

No, and expecting users to actually do so is a sign that something is very wrong about the process. TOFU turns out to be good enough for most purposes anyway, but if a key changes (perhaps the server was reimaged) then verifying it is about as friendly as a tax audit. Or using GPG.

SoftTalker 1y ago
Yeah that is my experience. Users don't understand public key cryptography. You ask them for their public key and they send you the private one. They use the same key everywhere. They don't understand the difference between a host key and a login key. Ask them to do anything with their authorized_keys file and your next ticket will be "I'm locked out of my system." They do understand passwords, and most can manage an SMS code as a second factor. That's about the limit of what you can count on.
- chuckadams 1y ago
  I've been doing this for 30 years and sometimes I give the wrong key file on the command line by forgetting to add '.pub' to the end. Far as I remember, I've always caught it before I managed to send it somewhere public, and thankfully most of my keys nowadays have a passphrase that gets remembered in my OS's keychain. But the UX is really that bad.
- franga2000 1y ago
  Users can understand asymmetric crypto, but the tools are so convoluted for no reason that they usually just give up. I've had no trouble explaining it to "average" computer users and they got it completely, but then actually using the tools for signing or authentication was the nearly impossible part. Your key has to parts: public and private. You give your public part to the server so it knows it's talking to you because only you have the private part. The server has its own pair and it gives you its public part so you know you're not talking to an impostor server. The private key is never sent, it stays on your computer, but it does some fancy math so the server can know you have it.
franga2000 1y ago
This is entirely the fault of the software. For planned key rotations, you could sign the new key with the old key and send that in the handshake, so the client could change the known_hosts file on its own. For unplanned rotations (server got nuked), you could isntruct your users to use a secure connection and run "ssh-replace-key server.example.com b3f620", which would re-run TOFU, with the last param being an optional truncated hash of the key for extra security. You could also do a prompt like "DANGER!! The host key has changed. If you know this is expected or of your IT administrator told you to do so, type 'I know what I'm doing or the IT admin told me to do this' ".

SoftTalker 1y ago

Yeah that is my experience. Users don't understand public key cryptography. You ask them for their public key and they send you the private one. They use the same key everywhere. They don't understand the difference between a host key and a login key. Ask them to do anything with their authorized_keys file and your next ticket will be "I'm locked out of my system." They do understand passwords, and most can manage an SMS code as a second factor. That's about the limit of what you can count on.

chuckadams 1y ago
I've been doing this for 30 years and sometimes I give the wrong key file on the command line by forgetting to add '.pub' to the end. Far as I remember, I've always caught it before I managed to send it somewhere public, and thankfully most of my keys nowadays have a passphrase that gets remembered in my OS's keychain. But the UX is really that bad.
franga2000 1y ago
Users can understand asymmetric crypto, but the tools are so convoluted for no reason that they usually just give up. I've had no trouble explaining it to "average" computer users and they got it completely, but then actually using the tools for signing or authentication was the nearly impossible part. Your key has to parts: public and private. You give your public part to the server so it knows it's talking to you because only you have the private part. The server has its own pair and it gives you its public part so you know you're not talking to an impostor server. The private key is never sent, it stays on your computer, but it does some fancy math so the server can know you have it.

franga2000 1y ago

This is entirely the fault of the software. For planned key rotations, you could sign the new key with the old key and send that in the handshake, so the client could change the known_hosts file on its own. For unplanned rotations (server got nuked), you could isntruct your users to use a secure connection and run "ssh-replace-key server.example.com b3f620", which would re-run TOFU, with the last param being an optional truncated hash of the key for extra security. You could also do a prompt like "DANGER!! The host key has changed. If you know this is expected or of your IT administrator told you to do so, type 'I know what I'm doing or the IT admin told me to do this' ".