I've had the flu and not been doing much until today when I finally got back to looking at this problem with ssh & x2go.
I've found a very good explanation of the error I am receiving after upgrading my x2go client & servers.
After entering my password in x2go client (ubuntu 11.10) and click OK I see... (sorry for the prev. embedded .PNG crap) !
AUTHENTICATION FAILED -Access denied. Authentication that can continue: publickey,keyboard-interactive
This URL describes the issues with SSH that are involved: http://fixunix.com/ssh/73976-difference-between-password-keyboard-interactive.html
in particular this seems like a very good explanation of the problem... although I haven't found out how to fix it ??10-03-2007 04:12 AM #3Re: Difference between password and keyboard-interactive
In article <1168327274.938793.197960@i15g2000cwa.googlegroups. com>
"Gushi" writes:
>I can't seem to find this anywhere.
See RFC 4252 (http://www.ietf.org/rfc/rfc4252.txt) which describes (among other things) the mandatory password method, and RFC 4256
(http://www.ietf.org/rfc/rfc4256.txt), which describes the optional keyboard-interactive method.
>What's the difference between password auth and keyboard-interactive?
>They'd seem to me to be the same thing, no?
Essentially, in password the client sends username+password and gets a yes/no response from the server, in keyboard-interactive the client sends the username, and then gets prompted (possibly multiple times, possibly zero times) by the server for additional information, before a yes/no response is finally sent by the server.
In the most common usage case, keyboard-interactive will prompt exactly once, for the user's password (well, it will typically re-prompt if the password is wrong:-), which to the user looks essentially the same as password authentication - the difference is mainly that in the password case, it is the client that prompts the user, while in keyboard-interactive, the client just relays the server's prompt (and
relays the response back).
However keyboard-interactive can thus support a variety of mechanisms besides single fixed password, e.g. challenge-response types where the server sends some random data, which the user feeds into a hardware token that generates a response for the user to type in. Being a perfect fit for PAM that is used on most current Unices, it allows for almost anything that you can plug into PAM to be used by ssh without any changes to the ssh code.
The password method on the other hand is a very bad fit for PAM, which is why for a while it wasn't possible to combine password and PAM in OpenSSH's sshd. In current versions sshd "fakes" the interaction towards PAM, by internally supplying the password that it has already received when PAM tries to prompt the user for it.
--Per Hedeland
per@hedeland.org