When connecting to a new system where the user (a) knows the server's pubkey fingerprint but (b) does not know the actual key data, there are two ways to validate the server key: 1. The interactive yes/no/fingerprint prompt 2. SSHFP records (DNS) The #1 isn't very automatable, and #2 is likely not available to an end user. Workarounds involving ssh-keyscan, base64 (decode), hashing, base64 (encode), fingerprint string construction, validation and writing to known_hosts are effective, but cumbersome. I'd very much like to have a command-line or configuration option that preempts the fingerprint validation question: ssh -o VerifyHostKeyString="SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8" <destination> ...or... ssh -o verifyHostKeyString="16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48" <destination> Additional minutiae: It seems to me that the supplied string can serve as a stand-in for the FingerprintHash argument (though it's not clear to me whether MD5 hash strings are expected to begin with "MD5:") The fingerprint presented to the user represents only one of the key types (the most preferred?) that the server holds. Should using this option require the user to specify the key type associated with the known fingerprint? Should the ssh client scan through all acceptable key types held by the server until it finds a match? It is my position that the rest of the key-handling behavior (writing to known_hosts on fingerprint acceptance) not change with this option: The known_hosts file gets updated in the usual way, use of the option to preempt fingerprint questions is a one-time deal. Thank you!
You can automate #1 by abusing SSH_ASKPASS. It's pretty clunky though, plus it'll end poorly if you need to interact to authenticate. $ ssh -o hostkeyalias=test localhost The authenticity of host 'test (127.0.0.1)' can't be established. ED25519 key fingerprint is SHA256:[etc]. Are you sure you want to continue connecting (yes/no/[fingerprint] ^C $ cat >~/bin/askpass #!/bin/sh echo SHA256:[etc] ^D $ chmod a+x ~/bin/askpass $ SSH_ASKPASS=~/bin/askpass SSH_ASKPASS_REQUIRE=force ssh -o hostkeyalias=test localhost Warning: Permanently added 'test' (ED25519) to the list of known hosts. Last login: ...
(In reply to bugzilla.mindrot.org from comment #0) > Workarounds involving ssh-keyscan, base64 (decode), hashing, base64 > (encode), fingerprint string construction, validation and writing to > known_hosts are effective, but cumbersome. This sounds too complicated. Running just ssh-keyscan and ssh-keygen should give you all you need, the key for known_hosts and fingerprint: $ ssh-keyscan github.com | tee /tmp/github.pub github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ== $ ssh-keygen -lf /tmp/github.pub 2048 SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 github.com (RSA) If you need also hash your hosts in known_hosts (for whatever obscure reason), ssh-keygen has a switch to do that too: $ ssh-keygen -Hf ~/.ssh/known_hosts
> Running just ssh-keyscan and ssh-keygen should give you all you need Yes, ssh-keygen can handle the 'base64; hash; base64; fingerprint string construction' steps. There's still the matter of calling both of those programs, storing the output, comparing the fingerprint strings and conditionally updating the known_hosts file. I can do these tasks, and am doing them today. If that's the workflow the community and maintainers intend, then I'll stick with it. It seemed reasonable to request (and I was encouraged to do so) because the ssh client already has two other built-in ways of doing fingerprint validation. I'm pretty amused that we managed to produce the same fingerprint string in our examples.