openssh bugs - Oct 2020 - [Bug 3226] New: Feature request: Prempt fingerprint prompt when connecting to new server

https://bugzilla.mindrot.org/show_bug.cgi?id=3226

            Bug ID: 3226
           Summary: Feature request: Prempt fingerprint prompt when
                    connecting to new server
           Product: Portable OpenSSH
           Version: 8.4p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: bugzilla.mindrot.org at marget.com

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 are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3226

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
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: ...

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3226

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #2 from Jakub Jelen <jjelen at redhat.com> ---
(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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3226

--- Comment #3 from bugzilla.mindrot.org at marget.com
---
> 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.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.