GNOME Bugzilla – Bug 318251
handle remote host identification change better
Last modified: 2009-03-17 21:07:12 UTC
GNOME properly asks for addion new host to .ssh/known_hosts, but does not know, how to interpret following message: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx. Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending key in /home/user/.ssh/known_hosts:11 RSA host key for example.org has changed and you have requested strict checking. Host key verification failed.
When is ist supposed to interpret this message? please give some steps how to reproduce this.
When the remote host changes its identification (new server, server installs new host keys and also "Man in middle" attack), ssh refuses to connect to the server and displays alert. gnome-vfs silently rejects the connection without any alert. Using ssh: If user knows, that the changed identification is OK, removing of ~/.ssh/known_hosts is needed. How to reproduce: Re-generate fresh /etc/ssh/ssh_host_* foles on remote machine and try to login by ssh and gnome-vfs. Proposed message for GNOME: Window title and/or bold text: "Security alert!" "The identity of the remote computer (%s) has changed." "This can happen only after remote system upgrade. " "Otherwise your communication is probably under attack!\n" "If you are not absolutely sure that it is safe to continue, contact the remote system administrator! " "The identity sent by the remote computer is %s." This should have two buttons - "Log In Anyway", "Cancel Login". Because automatic pressing "Log In Anyway" is very dangerous can do either "Edit ~/.ssh/known_hosts manually" or it should do double confirm - either by another confirmation with reverted confirmation buttons ("Are you absolutely sure that remote computer was reinstalled.", "Cancel Login", "Log In Anyway") or even better by typing confirmation: "Dangerous!\nOnly if you are absolutely sure that remote computer was upgraded, please type here \"Yes, I am absolutely sure.\" and press \"Log In Anyway\"."
Correction: If user knows, that the changed identification is OK, removing of ~/.ssh/known_hosts is needed. Should be: If user knows, that the changed identification is OK, removing of outdated line from ~/.ssh/known_hosts is needed.
I have seen this message as well before: If I modify ~/.ssh/known_hosts so that the error message quoted above appears when using ssh from console, a login attempt from Gnome 2.12.1 says "Error opening xxx". can you confirm that? anyways I believe we should handle this case better.
In nautilus 2.12.1 I see "Cannot display "ssh://myurl", i. e. generic error. And yes, modifying saved values in ~/.ssh/known_host is the simplest way to reproduce.
Confirming - we should handle this appropriately.
What do you propose? I don't think a new GmomeVFSResult is not enough, at least in the long term. We want a GUI and an automated edit of ~/.ssh/known_hosts.
*** Bug 334364 has been marked as a duplicate of this bug. ***
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/gnome-vfs2/+bug/45918 "sftp module can't handle partially valid hostkeys, gives confusing error desrt@moonpix:~$ ssh vanilla Warning: the RSA host key for 'vanilla' differs from the key for the IP address '71.19.4.161' Offending key for IP in /home/desrt/.ssh/known_hosts:91 Matching host key in /home/desrt/.ssh/known_hosts:95 Are you sure you want to continue connecting (yes/no)? yes desrt@vanilla's password: If I have this sort of error when connecting to a host over ssh then trying to open a nautilus window with sftp://vanilla/ locks for a while (30 seconds?) and then pops up this strange dialog: ------------------------------------ Could not open location 'sftp://vanilla/home/ian' Details: Unknown error code: 46 ------------------------------------"
*** Bug 306596 has been marked as a duplicate of this bug. ***
Did a resolution get proposed for this error then? The GUI does sound like a great idea with a text entry to confirm (typing 'yes' for example). Does it require significant changes to VFS?
openssh provides an utility to clear the key from known_hosts. ssh-keygen -R <offending hostname> will remove the hostname from the file. So removal can be left to the user by dropping the command that needs to be run to the user. Providing a GUI to do this, might make it too easy to remove the offending key and cause serious harm to network security.
*** Bug 392444 has been marked as a duplicate of this bug. ***
Created attachment 79411 [details] [review] Proposed patch I've put a lot of love into this patch! :) We'll have to handle all cases where either the hostname or the IP changed. I'm attaching a patch which puts this into (hopefully) more understandable phrases as the OpenSSH client. Concerns: 1. OpenSSH specific (can be fixed) 2. Evil hack by principle (massive stdout parsing, no real "API")
Created attachment 79412 [details] Python script that will issue some gnomevfs-info testcases This specially prepared python script will test all possible combinations of host/IP authentication issues. Note that it will delete ~/.ssh/known_hosts. It will do a request for "svn.gnome.org" which will eventually fail with an I/O error, but that isn't relevant. Below is a typical output that should help our usability crew to check out the strings (I know that's a lot of text, sorry). ./gnome_vfs_sftp_testcases.py >>> Testcase: host OK, IP OK Error: I/O error >>> Testcase: host OK, IP unknown Error: I/O error >>> Testcase: host unknown, IP OK The identity of the remote computer (svn.gnome.org (82.211.81.213)) is unknown. ========== This happens when you log in to a computer the first time. The identity sent by the remote computer is 0a:c8:87:02:4a:0f:5e:18:c8:e5:9a:9e:40:00:8c:f6. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Log In Anyway 2 Cancel Login 1 Error: I/O error >>> Testcase: host unknown, IP unknown The identity of the remote computer (svn.gnome.org (82.211.81.213)) is unknown. ========== This happens when you log in to a computer the first time. The identity sent by the remote computer is 0a:c8:87:02:4a:0f:5e:18:c8:e5:9a:9e:40:00:8c:f6. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Log In Anyway 2 Cancel Login 1 Error: I/O error >>> Testcase: host OK, IP changed Host Identity Of "svn.gnome.org" Did Not Change, But Identity Of IP "82.211.81.213" Did Change. ========== The identity associated with the host "svn.gnome.org" has not changed since your last access, while the identity of the associated IP "82.211.81.213" has changed. This may have various reasons. For instance, the server may have been changed its IP address, which you formerly used to access another server. This is mainly relevant in small networks, and very unlikely in the internet. Note: It is possible that you are the victim of eavesdropping. Another machine could pretend to be the host you contacted, and log the data you send, afterwards forwarding it to the desired host (also known as "man-in-the-middle" attack). You can either cancel the login attempt, or request to discard the stored last known identity associated with "82.211.81.213" and log in. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Clear And Continue 2 Cancel Login 1 /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old Error: I/O error >>> Testcase: host changed, IP OK Host Identity Of "svn.gnome.org" Changed, But Identity Of IP "82.211.81.213" Did Not Change. Possible DNS Spoofing Detected! ========== The identity associated with the host "svn.gnome.org" has changed to "0a:c8:87:02:4a:0f:5e:18:c8:e5:9a:9e:40:00:8c:f6" since your last access, but the identity of the associated IP "82.211.81.213" did not change. This may have various reasons. For instance, the server may have been replaced with another machine that you previously accessed under another host name (or directly). This is mainly relevant in small networks, and very unlikely in the internet. Note: It is possible that you are the victim of eavesdropping. Another machine could pretend to be the host you contacted, and log the data you send, afterwards forwarding it to the desired host (also known as "man-in-the-middle" attack). You can either cancel the login attempt, or request to discard the stored last known identitiy associated with "svn.gnome.org" and log in. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Clear And Continue 2 Cancel Login 1 /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old Error: I/O error >>> Testcase: host unknown, IP changed The identity of the remote computer (svn.gnome.org (82.211.81.213)) is unknown. ========== This happens when you log in to a computer the first time. The identity sent by the remote computer is 0a:c8:87:02:4a:0f:5e:18:c8:e5:9a:9e:40:00:8c:f6. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Log In Anyway 2 Cancel Login 1 Host Identity Of "svn.gnome.org" Did Not Change, But Identity Of IP "82.211.81.213" Did Change. ========== The identity associated with the host "svn.gnome.org" has not changed since your last access, while the identity of the associated IP "82.211.81.213" has changed. This may have various reasons. For instance, the server may have been changed its IP address, which you formerly used to access another server. This is mainly relevant in small networks, and very unlikely in the internet. Note: It is possible that you are the victim of eavesdropping. Another machine could pretend to be the host you contacted, and log the data you send, afterwards forwarding it to the desired host (also known as "man-in-the-middle" attack). You can either cancel the login attempt, or request to discard the stored last known identity associated with "82.211.81.213" and log in. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Clear And Continue 2 Cancel Login 1 /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old Error: I/O error >>> Testcase: host changed, IP unknown Host Identity Of "svn.gnome.org" Changed, But Identity Of IP "82.211.81.213" Is Unknown. Possible DNS Spoofing Detected! ========== The identity associated with the host "svn.gnome.org" has changed to "0a:c8:87:02:4a:0f:5e:18:c8:e5:9a:9e:40:00:8c:f6" since your last access, while the identity of the associated IP "82.211.81.213" could not be determined. This may have various reasons. For instance, the server may have a dynamic IP address that changed since your last visit, and its host key has recently been changed. Note: It is possible that you are the victim of eavesdropping. Another machine could pretend to be the host you contacted, and log the data you send, afterwards forwarding it to the desired host (also known as "man-in-the-middle" attack). You can either cancel the login attempt, or request to discard the stored last known identitiy associated with "svn.gnome.org" and log in. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Clear And Continue 2 Cancel Login 1 /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old Error: I/O error >>> Testcase: host changed, IP changed - both match Host Identity Of svn.gnome.org Changed, But Matches IP Identity. ========== The identity associated with the host "svn.gnome.org" and its IP address have both changed to the same identity since your last access. This may have various reasons. For instance, the server may have been replaced with another machine. Note: It is possible that you are the victim of eavesdropping. Another machine could pretend to be the host you contacted, and log the data you send, afterwards forwarding it to the desired host (also known as "man-in-the-middle" attack). You can either cancel the login attempt, or request to discard the stored last known identities associated with "svn.gnome.org" and its IP address and log in. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Clear And Continue 2 Cancel Login 1 /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old Error: I/O error >>> Testcase: host changed, IP changed - both mismatch Host Identity Of "svn.gnome.org" And Identity Of IP "82.211.81.213" Changed, But Identities Do Not Match. Possible DNS Spoofing Detected! ========== The identity associated with the host "svn.gnome.org" has changed to "0a:c8:87:02:4a:0f:5e:18:c8:e5:9a:9e:40:00:8c:f6" since your last access, while the identity of the associated IP "82.211.81.213" has changed to another identity. This may have various reasons. For instance, the server may have been replaced with another machine that you previously accessed under another host name (or directly), and the current IP address might have been used by another server. This is mainly relevant in small networks, and very unlikely in the internet. Note: It is possible that you are the victim of eavesdropping. Another machine could pretend to be the host you contacted, and log the data you send, afterwards forwarding it to the desired host (also known as "man-in-the-middle" attack). You can either cancel the login attempt, or request to discard the stored last known identities associated with "svn.gnome.org" and "82.211.81.213" and log in. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Clear And Continue 2 Cancel Login 1 /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old /home/chris/.ssh/known_hosts updated. Original contents retained as /home/chris/.ssh/known_hosts.old Error: I/O error
Created attachment 79413 [details] [review] Proposed programs/authentication.c fixes Slightly related patch for program/authentication.c that will make a clear distinction between primary and secondary message in command line applications (used above), and fixes a few logical mistakes.
CCing usability-maint. It would be great if anybody could look through comment 15 and check out whether the individual >>> Testcase messages are understandable to the experienced computer user (average people usually don't deal with sftp). Maybe you could give some comments on the wording and length? The one-liners above the "======" are supposed to be the primary dialog messages, those below are the secondary messages.
I'd love to see the patch implemented because i just ran into that situation of connecting to a computer with a freshly installed linux and a therefore changed key on that host/ip. Nautilus complained about an unknown error 46. I took a look at the comment #15 but did not check for all options in the sshconnect.c in openssh. But there is a special case like readonly in that switch/case tree i could not find in the dialogs from christian. Some suggestions: > The identity of the remote computer (svn.gnome.org (82.211.81.213)) is unknown. > ========== > > This happens when you log in to a computer the first time. > > The identity sent by the remote computer is > 0a:c8:87:02:4a:0f:5e:18:c8:e5:9a:9e:40:00:8c:f6. If you want to be absolutely > sure it is safe to continue, contact the system administrator. > 1 Log In Anyway > 2 Cancel Login > 1 > Error: I/O error Okay but i would prefer: 1 Continue Login 2 Cancel I'd prefer to have the word login not inside the cancel button but in the button that will take you to the login. And i think its allways better to leave cancel stand allone. Activating the primary text could be done with a expander if the dialog resizes. (Just like the expander in the save as dialog works. Little more work though.) >>> Testcase: host changed, IP OK >>> Testcase: host changed, IP unknown ...ok... > You can either cancel the login attempt, or request to discard the stored last > known identitiy associated with "svn.gnome.org" and log in. > If you want to be absolutely sure it is safe to continue, contact the system > administrator. > 1 Clear And Continue > 2 Cancel Login > I'd prefer: You can either cancel the login attempt, or request to update the known identitiy associated with "svn.gnome.org" and log in. If you want to be absolutely sure it is safe to continue, contact the system administrator. 1 Update And Continue Login 2 Cancel I just gladed a dialog to proof its not to long and think this is still okay. I'd prefer Update over Clear because the identity is replaced with the new one and update is what you use in the result "home/chris/.ssh/known_hosts updated.". >>> Testcase: host changed, IP changed - both match ...ok... > You can either cancel the login attempt, or request to discard the stored last > known identities associated with "svn.gnome.org" and its IP address and log in. > If you want to be absolutely sure it is safe to continue, contact the system > administrator. > 1 Clear And Continue > 2 Cancel Login As above please replace discard and clear with update.
Updating version; cc'ing myself; and pretty-please poking the usability folks. Would be really nice to get this into 2.18.1 :/
This works a lot better for me now with Gnome 2.24 and gvfs, the replacement for deprecatred gnome-vfs. I.e. the "remote host fingerprint changed" message is interpreted and an appropriate dialogue displayed giving some brief explanations. I think this report should be closed OBSOLETE.
A lot from Comment #18 is reality with gvfs in Gnome 2.24; there has not been any activity in this bug for 6 months, and gnome-vfs is deprecated anyways and has been replaced. Closing this report as OBSOLETE.