I am too paranoid to say "yes, continue connecting" blindly (yes, I know I am wierd <g>) but I am also too lazy to compare fingerprints manually or keep known_hosts on all my machines synchronized. Fortunately, I have found a way to make my life easier: if I patch ssh to interpret a matching fingerprint as "yes", I can copy & paste the expected fingerprint from a different place (file, ssh-keygen -l on another machine) with several mouse movements and let ssh do the hard work itself. :) Well, I do not really think you will make such a change in the official version. Anyway, here is a patch I made just in case someone finds it useful: diff -urN openssh-3.0.2p1.old/sshconnect.c openssh-3.0.2p1/sshconnect.c --- openssh-3.0.2p1.old/sshconnect.c Wed Oct 10 07:07:45 2001 +++ openssh-3.0.2p1/sshconnect.c Wed Feb 6 02:19:58 2002 @@ -487,7 +487,7 @@ /* defaults to 'no' */ static int -confirm(const char *prompt) +confirm(const char *prompt, const char *altyes) { char buf[1024]; FILE *f; @@ -515,6 +515,8 @@ retval = 1; else if (strcmp(buf, "no") == 0) retval = 0; + else if (altyes != NULL && strcmp(buf, altyes) == 0) + retval = 1; else fprintf(stderr, "Please type 'yes' or 'no': "); @@ -697,10 +699,11 @@ "%s key fingerprint is %s.\n" "Are you sure you want to continue connecting " "(yes/no)? ", host, ip, type, fp); - xfree(fp); - if (!confirm(prompt)) { + if (!confirm(prompt, fp)) { + xfree(fp); goto fail; } + xfree(fp); } if (options.check_host_ip && ip_status == HOST_NEW) { snprintf(hostline, sizeof(hostline), "%s,%s", host, ip); @@ -815,7 +818,7 @@ goto fail; } else if (options.strict_host_key_checking == 2) { if (!confirm("Are you sure you want " - "to continue connecting (yes/no)? ")) { + "to continue connecting (yes/no)? ", NULL)) { goto fail; } }
Heh, I kinda like that. You should update the yes/no prompt to say that pasting the expected host key will result in appropriate testing, as well as providing some sort of error if the remote side *doesn't* match the key pasted in. I hadn't thought of cut and paste as useful like that. --Dan
i think this is cool idea. do you want to write documentation for this?
I can do it (now when I know other people like such a feature) but I am not sure what kind of documentation (besides proper prompts and other messages from ssh) should be written? Should this behaviour be described in ssh.1? Or elsewhere?
I'd like to propose a slight modification to the feature, because I'm concerned that unsophisticated users may use it incorrectly. If the SSH client outputs a fingerprint, and then prompts the user to enter the fingerprint for the host, a user who does not understand the purpose of this procedure may simply cut and paste the fingerprint that was just displayed. Although this is no less secure than the user simply typing "yes" to accept the host identification blindly, it may result in a false sense of security for users who do not understand the purpose of the key fingerprints. This problem could be addressed by introducing a client-side option which controls whether the client should handle an unknown host by: a) displaying the fingerprint and prompting for yes/no (as previously); or b) not displaying the fingerprint by default, and instead prompting for the user to enter the host's fingerprint. This option would be set to do (a) by users who generally wish to compare fingerprints manually, and to (b) by those who generally wish to have ssh do the comparison for them. In the case of (b), this could be enhanced so that the user can type "yes" to accept the host key sight-unseen, or "show" to display the fingerprint and re-prompt. Just a suggestion.
I have modified the patch to accept "yes"/"no"/"check". When you say "check", it prompts for a fingerprint ("Enter the expected key fingerprint (DO NOT copy the fingerprint that might have been displayed earlier)"), compares it with the key received from the server, and prints the result ("The fingerprints match." / "The fingerprints do not match.").
Created attachment 28 [details] improved fingerprint checking patch against CVS
Would it be better not to display the foriegn finger print in check mode? This may ensure that the user is not cutting and pasting the wrong entry. - Ben
One could print the foreign id with dots instead of colons. Then refuse that format on input. That way you can not just simply cut'n'paste it.
But the whole *point* of the patch is to cut and paste it--from a trusted source. This would usually be "ssh-keygen -l", but it could also be the output of another previous ssh session (run from a more trustworthy context). Poisoning the format of the displayed fingerprint is an ugly approach; with all due respect, the only argument for taking that tack is that it's easier to code than designing it correctly (i.e., in such a manner that it doesn't spit out the answer to the question it's asking.)
nice idea, but i don't think this will happen.
Mass change of RESOLVED bugs to CLOSED