GNOME Bugzilla – Bug 551585
When setting up a key for ssh for the first time a very confusing messagebox appears.
Last modified: 2018-08-03 19:12:28 UTC
Please describe the problem: I just created an ssh key and set up another machine to recognise it using the wizard that is part of the key creation wizard. I had already connected to the other machine using ssh password authentication. This worked flawlessly. I then wanted to set up another machine that I hadn't previously accessed. I selected the "Set up computer for Secure Shell" option and filled in the hostname. I was then given a password prompt as before, but the message was different, instead of "<username> password for <hostname> (<ip address>)" I had "Authenticity of the host key for <hostname> (<ip address>) cannot be established". Entering my password in to that dialog gave an error dialog with the same message and the wizard quit. I figured that I had to type yes in this dialog to accept the identification of the remote host. Steps to reproduce: 1. Create a SSH-Key 2. Use the wizard to automatically setup a remote host that you never accessed before (or deleted from ~/.ssh/known_hosts) Actual results: A messagebox appears with the text "Authenticity of the host key for <hostname> can't be established" and a prompt for entering password. Expected results: A choose between yes and no if want to trust the authenticity would be the best solution. But it is sufficient if instead of passphrase there would be a message saying "Type in 'yes' or 'no'". Does this happen every time? Yes - If the host is not in known_hosts Other information: This issue has been reported on Launchpad: https://bugs.edge.launchpad.net/ubuntu/+source/seahorse/+bug/183643
This will have to wait until after we branch for 2.24.
This appears to be a bug in the ssh-agent provided by gnome-keyring. I'll attach a screenshot.
Created attachment 123004 [details] shows bad dialog
OK, now i made some testing using 2.25.92: Precondition for all test is that the remote host is not known yet. Test Case 1: In the messagebox "Authenticity of the host key for <hostname> can't be established" I type in my Password, as requested. Result: 1. A Messagebox "Please type 'Yes' or 'No'" appears, accepting no input. (The text is the response from ssh when entering anything but yes or no on the commandline. 2. An Errorbox appears, with bolded text "Couldn't configure Secure Shell keys on remote computer." Below that: "Host key verification failed." Only button is "Close". Upon closing: Crash. (see backtrace i attach.) -------------------- Test Case 2: In the messagebox "Authenticity of the host key for <hostname> can't be established" I type in "yes", the answer to the question, ssh would ask on the command-line. Result: 1. A Messagebox appears, saying bolded "Password" and below again "Password", fully accepting input. Here I enter my Password and Click "OK". 2. On the remote side, the login is successful and the key gets added to ~/ssh/authorized_keys. 3. The password prompt comes up again, but the program crashes immediately with a backtrace similar to testcase 1. ---------------------------------- Testcase 3: New Preondition: The ssh key is already known on the server. In the messagebox "Authenticity of the host key for <hostname> can't be established" I type in "yes", the answer to the question, ssh would ask on the command-line. Result: I get logged in (due to the key known and used) and seahorse does not crash. ----------------- I hope that helps you find the problem.
Created attachment 129913 [details] a backtrace from testcase 1
Created attachment 129914 [details] a backtrace from testcase 2
Yes, we need to fix this. But that dialog is put up by seahorse. We basically have to do screen scraping to figure out when to show the "I want to connect to this new host" dialog. In fact we should have a look at how gvfs does it, because their dialog works rather well.
*** Bug 563209 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/seahorse/issues/23.