Bug 3226

Summary: Feature request: Prempt fingerprint prompt when connecting to new server
Product: Portable OpenSSH Reporter: bugzilla.mindrot.org
Component: sshAssignee: Assigned to nobody <unassigned-bugs>
Status: NEW ---    
Severity: enhancement CC: dtucker, jjelen
Priority: P5    
Version: 8.4p1   
Hardware: All   
OS: All   

Description bugzilla.mindrot.org 2020-10-30 12:22:52 AEDT 
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!
Comment 1 Darren Tucker 2020-10-30 18:02:29 AEDT 
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: ...
Comment 2 Jakub Jelen 2020-10-31 03:22:14 AEDT 
(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
Comment 3 bugzilla.mindrot.org 2020-10-31 03:48:39 AEDT 
> 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.