Bug 2493

Summary:	Accept host key fingerprint as the same as 'yes'
Product:	Portable OpenSSH	Reporter:	micah
Component:	ssh	Assignee:	Assigned to nobody <unassigned-bugs>
Status:	CLOSED FIXED
Severity:	enhancement	CC:	djm, dkg, jjelen
Priority:	P5
Version:	6.9p1
Hardware:	Other
OS:	Linux

Description micah 2015-11-10 15:42:22 AEDT

Maybe this is a terrible idea, but it seems like a great, and simple improvement.

When prompted with this dialog:

The authenticity of host 'blah.blah.blah (10.10.10.10)' can't be established. RSA key fingerprint is a4:d9:a4:d9:a4:d9a4:d9:a4:d9a4:d9a4:d9a4:d9a4:d9a4:d9.
Are you sure you want to continue connecting (yes/no)?

1. I want to verify this key

2. if its a new system, I use ssh-keygen -lf to print out the host's fingerprint so I can compare it

3. if its the first time I've installed openssh-server on debian, it prints out the just generated host key fingerprint to stdout

4. if its not a new system, but a shared/collaboratively managed one, I have the host key fingerprint either in a file, or someone has provided it to me over a secure channel.

In order for me to verify the key (#1) in any of the cases #2-4 I have to visually inspect each character, comparing it one by one. A tedious, but necessary process. In all the cases, I already have the fingerprint available to me, but I have to pass it through my human-fallible visual comparison process. Its so annoying and prone to failure, that I'm discouraged from doing it.

What if I didn't have to pass it through my eyes, into my short-term memory, and then compare it with the other one on the screen... and instead I could just copy the known-good, verified key fingerprint from another location and simply paste it into the dialog asking me for confirmation and that would accept it in the same way that typing 'yes' would accept it?

In otherwords, what if the equivalent to 'yes' was the user typing in the host key's fingerprint? Sure, the user can just copy and paste what is presented there, which wont help them, but most people will also just type 'yes' without checking the fingerprint as well, so it is no degradation to the existing status-quo.

Comment 1 Jakub Jelen 2015-11-11 00:44:58 AEDT

I really like this idea. I was thinking about this step many times, but this solution seems really elegant, if there is no CA or SSHFP.

The best thing is always to get the whole public key you can store by hand in your known_hosts. But having only fingerpint makes it more difficult and this feature would basically solve it.

This would allow us to leave both methods available (yes/no checking or pasted fingerprint). It would be also helpful for the new fingerprint methods using SHA256 and base64, which is even harder to read and compare.

> The authenticity of host 'somehost (10.0.0.1)' can't be established. ECDSA key fingerprint is SHA256:9hT+deeJW3NzlzBXvJ3eK/lr7QYmxaZweHqzPG2WASU.
> Are you sure you want to continue connecting (yes/no)? 
> Or you can verify the fingerprint by writing it here: |

It would also solve the issue with different hashes which can be problem at the moment, when connecting with new client (6.8+) to old machine (as described in bug #2439).

The texts would probably needs a bit tweaking, but yes, the concept sounds great.

Comment 2 Daniel Kahn Gillmor 2015-11-12 05:16:43 AEDT

I also like this idea.

If you have the host key or its fingerprint already available, you should be able to just add it to your known_hosts file *before* you connect to the machine, but that's not a realistic workflow for most people.

So Micah's suggestion is a good one that i think integrates well with common workflows.

Comment 3 Damien Miller 2020-01-25 23:14:56 AEDT

This feature has been available since openssh-8.0

Comment 4 Damien Miller 2021-04-23 15:02:28 AEST

closing resolved bugs as of 8.6p1 release