Bug 1843 - ssh should mention ssh-keygen in remote host fingerprint warning
Summary: ssh should mention ssh-keygen in remote host fingerprint warning
Status: CLOSED WONTFIX
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh (show other bugs)
Version: 5.6p1
Hardware: All All
: P2 minor
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-10 02:59 AEDT by Scott Moser
Modified: 2016-08-02 10:41 AEST (History)
4 users (show)

See Also:


Attachments
patch (1.13 KB, patch)
2010-12-10 02:59 AEDT, Scott Moser
no flags Details | Diff
use ip/host not ip_line/host_line (1.03 KB, patch)
2010-12-14 22:51 AEDT, Colin Watson
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Moser 2010-12-10 02:59:27 AEDT
Created attachment 1972 [details]
patch

ssh should mention ssh-keyscan when it warns about remote host fingerprint.

I find that many people are unaware that ssh-keygen can remove lines from known_hosts for them.
adding a copy-and-pasteable message in the warning will make users
more aware and make it easier for them to do so.
Comment 1 Scott Moser 2010-12-10 03:05:26 AEDT
I'd also sent this to the mailing list:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2010-December/029084.html
Comment 2 Colin Watson 2010-12-14 22:51:05 AEDT
Created attachment 1977 [details]
use ip/host not ip_line/host_line

I think Scott picked out the wrong version of this patch to send; -R <ip_line> can't possibly work.  Here's a corrected version.
Comment 3 Darren Tucker 2010-12-15 21:23:01 AEDT
I think encouraging cut-and-pasting something in response to a key mismatch warning instead of having peopek *thinking* about the key change and why it changed is
Comment 4 Darren Tucker 2010-12-15 21:23:59 AEDT
(In reply to comment #3)
> I think encouraging cut-and-pasting something in response to a key
> mismatch warning instead of having peopek *thinking* about the key
> change and why it changed is

bah.

"I think encouraging cut-and-pasting something in response to a key
mismatch warning instead of having people *thinking* about the key
change and why it changed is not a good idea"
Comment 5 Scott Moser 2010-12-16 01:48:18 AEDT
I expected the "make it hard to do so people know what they're doing response".  I really don't think its all that valid.  The user is still forced to take manual action, finding, selecting, and pasting the command line.

The "finding" is non-trivial, and in the output message (with example below), the most obvious and important warning message still stands out.


@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
c5:43:dd:69:56:82:2c:30:4c:03:57:45:aa:de:26:31.
Please contact your system administrator.
Add correct host key in /home/smoser/.ssh/known_hosts.uec to get rid of this message.
Offending key in /home/smoser/.ssh/known_hosts.uec:1
  remove with: ssh-keygen -f "/home/smoser/.ssh/known_hosts.uec" -R kearney
RSA host key for kearney has changed and you have requested strict checking.
Host key verification failed.
Comment 6 Christoph Anton Mitterer 2015-11-01 13:33:58 AEDT
But in reality it's probably still simple the case the novice users may assume that text/command to be a recommendation and ignore the previous warnings.

Anyway... error messages aren't the proper place to tell users any possible reasonable next-step to do.
Therefore one has documentation and how-tos. So your motivation is probably in fact to make that for a quick copy&paste, and that shouldn't be part of OpenSSH.
Comment 7 Darren Tucker 2015-11-02 09:37:09 AEDT
Sorrym, but having the error message suggest something that is exactly the wrong thing to do in the case of an active MITM attack is not something we want to do.
Comment 8 Damien Miller 2016-08-02 10:41:42 AEST
Close all resolved bugs after 7.3p1 release