Review Request: More kio_sftp login related fixes

Sun May 13 21:16:37 BST 2012

> On April 21, 2012, 9:05 a.m., Andreas Schneider wrote:
> > Did you also test if keyboard-interactive still works correctly?
> 
> Dawit Alemayehu wrote:
>     No, because I do not even know how to enable that functionality in my ssh config and was lazy to search and find out. Just looking at the code though I immediately see a problem where it sets the error message in the first dialog box which will cause the retry dialog to be shown. I dunno if that was intentional, but it is wrong. The user will not only see the message sent from the ioslave, but also gets the question "Do you want to retry?".
>     
>     BTW, I take back what I stated in the description of problem #1. It is not my last patch that caused the bug. It is there prior to my patch as well since I checked out and tested v4.8.0 to see if that was the case. Anyhow, I can try to see if I can figure out how to enable keyboard interactive mode and test that too. 
>     
>     For the record I did not actually set out to fix these issues in kio_sftp. It resulted from my work on fixing problems in kpasswdserver. I needed someway to test those changes and the ssh server happens to be something that is already up and running on my system. Lucky kio_sftp. ;)
> 
> Andreas Schneider wrote:
>     Normally password authentication is turned off in the ssh server (default for openssh) and keyboard interactive is used. There are some flaws in password authentication and keyboard-interactive is a much more flexible way. So if you have current Linux distribution then password authentication is turned of and you have keyboard-interactive authentication connecting to localhost.
>     
>     Thanks for all the fixes. I don't have time for libssh and kio_sftp lately. There are other projects I need to drive forward right now :)
> 
> Dawit Alemayehu wrote:
>     Well I finally had the time to figure out how to activate keyboard interactive and completely cleaned up the sftp login code to make it more readable. I removed the usage of the go to statement to avoid iterating through all the authentication methods just to retry password authentication. However, for the life of me I cannot figure out how the authenticateKeyboardInteractive is supposed to work. For me it does not work at all because it does not prompt me for the password. I read documentation you provided at http://api.libssh.org/stable/libssh_tutor_authentication.html. 
>     
>     What I gathered from reading the documentation is that, in keyboard interactive mode, the server can send a challenge for which the user is supposed to provide an answer. The server indicates that it is sending such challenge prompt by setting the echo parameter to 1. Is that correct ? If it is, how that is then handled is rather befuddling to me. For example, the errorMsg parameter of the openPassword function is always set to the same text. That will cause the retry dialog to be shown with the "Do you want to retry?" question mark. Was that intentional ? What is being achieved by that. I would have tested it myself I had known what option to set in sshd_config to make the server send such challenge. I am sure if 
>     
>     The scenario I was able to test on my system is where the echo parameter is set to 0 and the prompt is set to "Password". In that case for some reason, the user is never prompted to enter the password. Instead the value of mPassword is assigned to it. Was that because the other password dialog (one used for authentication) was used to prompt for username and password already ? Anyhow, I have attached the latest incarnation which cleans up all the previous authentication related changes I made. It is much cleaner and easier to understand the flow of the authentication code now.
> 
> Andreas Schneider wrote:
>     Keyboard interactive can ask for the username and 10 questions about Star Wars before it will ask you for the password. You don't know how the password question will look but in most of the cases it is "Password:". So there should be a case handling username + "Password:" question.
>     
>     You can also simply extend keyboard interactive. Ask for password + a one time password from a token. This way it is pretty flexible. The 'echo' flag is just for your if you should echo to the console what the server asks or not. If echo is set we should use a Password field instead of a normal input field.
>     
>     I don't know what you mean with the errorMsg. I don't see something in the authenticateKeyboardInteractive() function.
> 
> Dawit Alemayehu wrote:
>     Right. I gathered keyboard interactive can ask multiple questions before it asks for the password. What I am baffled about is how it is currently being handled in authenticateKeyboardInteractive. Perhaps it would have been clearer if I simply stated the problems that I have after testing and reading the code in the "authenticateKeyboardInteractive" function. Here are the two issues I have:
>     
>     #1. The first call to openPasswordDialog, the one whose first parameter is "infoKbdInt", always sets an error message. The text that says "Use the username input field to answer this question." is the error message and will result in the "retry" dialog being shown (See SlaveBase::openPasswordDialog docs). Unfortunately, I am not able to test that code path because the call to ssh_userauth_kbdint_getprompt returns sets the echo value 0 on my machine. Since I have not yet figured out how to configure my ssh server to do otherwise, I am not able to literally test it. Still, from looking at the code, it is obvious that the retry dialog is used to display the aforementioned "error message" before the user is prompted for login name and a password. Was that done on purpose ?
>     
>     #2. When testing keyboard interactive, the call to "ssh_userauth_kbdint_getprompt" in authenticateKeyboardInteractive returns "echo = 0" and "prompt = Password" on my machine. As a result I never get prompted to enter a password because the code path for this scenario simply set the "answer" variable to whatever mPassword happens to be set to (including nothing). Hence, keyboard interactive always fails for me. What I do not understand is why when the "prompt" is set to "Password", there is no prompting the user for a password ?

To #1: I didn't know that it triggers a reply. I needed to ask questions without a password field so I used the standard dialog. Maybe it is more advanced since 4.0. However if you compile libssh from source there is a kbdint server example which asks questions about hitchhikers guide to the galaxy ;)
Maybe this changed since I wrote it. I looked for a way to ask the user the questions.

To #2: The idea was to prompt the user for a password and then to into kbding and password userauth. So if he entered a password already and kbdint asks for Password then we just use the one he already entered. I think after all the great work you've to this doesn't work as before.

Could you try the libssh kbdint server example? If something doesn't work, let me know and I will change or fix the example.

Thanks for your work and help on this!

- Andreas

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104642/#review12748
-----------------------------------------------------------

On April 26, 2012, 3:42 a.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104642/
> -----------------------------------------------------------
> 
> (Updated April 26, 2012, 3:42 a.m.)
> 
> 
> Review request for KDE Runtime and Andreas Schneider.
> 
> 
> Description
> -------
> 
> This is the last one of the sftp login fixes series and addresses the following problems:    
> 
> #1. Correctly handle login failure that results from a different username being used when setting the 
> SSH_OPTIONS_USER option and calling ssh_userauth_password. I think this might have been due to
> a regression caused by my previous patch. Nonetheless, this patch addresses it.
> 
> #2. Changed public key authentication so that incorrect public key passwords generate a retry dialog
> instead of simply continuing to the next available authentication method.
> 
> 
> Diffs
> -----
> 
>   kioslave/sftp/kio_sftp.h f497c0b 
>   kioslave/sftp/kio_sftp.cpp e38c629 
> 
> Diff: http://git.reviewboard.kde.org/r/104642/diff/
> 
> 
> Testing
> -------
> 
> Testing for #1:
> ===========
> 1.) Make sure a ssh server is running on your system.
> 2.) Attempt to login into your system: sftp://127.0.0.1.
> 3.) When prompted for credentials, enter a user name other than the currently logged in user.
> 
> Current Behavior:
> Login attempt will simply fail eventually and and error page is displayed.
> 
> New (Fixed) Behavior:
> Successfully log into the server with the specified user name.
> 
> 
> Testing for #2:
> ===========
> 1.) Create a ssh key with password protection and add it to the authorized_keys file.
> 2.) Make sure the ssh public key is in your .ssh directory.
> 3.) Attempt to login into your system: sftp://127.0.0.1
> 4.) When prompted for the passpharse for the key, enter a bogus password. 
> 
> Current behavior:
> No retry dialog is ever shown for an invalid or improper ssh key passphrase and the process simply moves on to the next authentication method.
> 
> New(Fixed) behavior:
> Show a retry dialog if the failure is due to invalid password. If the user then presses cancel on the retry dialog, simply behave the same way as if the cancel button is pressed on the password dialog. That is continue onto the next authentication method.
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120513/0ae61f03/attachment.htm>