> 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.

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.


- 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
> 
>

Reply via email to