[X2Go-User] Can't solve error: "Access denied. Authentication that can continue: publickey, password"

[Stefan Baur]

Hello Franziska,

Am 06.11.19 um 10:45 schrieb Franziska Goltz:
> Hi,
> 
> I am trying to run x2go with a macOS Mojave client and a Ubuntu 18.04
> server. When trying to connect, I keep getting the following error:
> "Access denied. Authentication that can continue: publickey,password".
> It seems like this is an error other people had before, so I tried
> multiple things that were suggested on various feeds, but nothing
> helped. I tried logging in with a different user, changed the user
> passwords, changed the passkey of my private key,

Changing the passphrase of your private key should never be necessary to
solve connection issues.
That passphrase does not leave your machine, it merely unlocks the
content of your private key, so to speak.  The key will always remain
the same, even if you change the passphrase (else you would have to
update the authenticated_keys file on all servers upon a passphrase
change - which you do not).
Whoever suggested this to you has no clue of how ssh public/private key
authentication works.


> I tried all combinations of the
> "PasswordAuthentication","ChallengeResponseAuthentication" and
> "PubkeyAuthentication" settings in my sshd_config file.

This, too, should never be neccessary provided logging in with a regular
SSH client and the same credentials works.


> I checked
> whether the correct key is in the authorized_keys file, I checked that
> the .ssh directory and the authorized_key have the correct permissions.

This is good advice and indeed something that needs to be checked when
encountering authentication issues.
Did you also check the client side?  On the client, your private key
file needs to be owned by you and have permissions 0600 (that is,
read/write for your user, and inaccessible for everyone else).
It is usually stored in ~/.ssh/ - which in your case, expands to
/Users/Franziska/.ssh/ - and .ssh should again be owned by you and have
permissions 0700.
If you want to make the private key you are using the default key for
all your ssh connections, the file should be named id_rsa (as hinted by
the error message you quoted below).  If not, any other name will do,
just make sure ownership and permissions are set up correctly as
described above.


> I restarted multiple times and tried changing the presettings of my
> connection, e.g. I tried not entering the directory for my private key,
> which gives me an additional error saying: "Failed to read private
> key:/Users/Franziska/.ssh/id_rsa". 

*If* you are specifying a keyfile, then the entry should indeed include
a path.  It may be a relative path (e.g. ../some/where/else/mykey) or
one using the usual ~ shortcut for your home directory, like
~/.ssh/mykey for /Users/Franziska/.ssh/mykey.


> Using a normal OpenSSH client and
> logging on to the server via the command line works fine. I don't really
> know what more to try so I would be very grateful for any kind of help!

The question is what your ssh client might be doing differently than
X2Go's built-in ssh client.

I would suggest the following:

1) In a Terminal, run the following commands and post the output:

echo $SSH_AUTH_SOCK
ssh-add -l # that's a lower-case L, not an upper-case i, nor a digit 1

This should tell us if you have an SSH-Agent running, and if it already
knows your key.

2) Next, run the ssh command you used to connect to your server, but
with the added parameter -vvv (that's three "v"s). Also post that output
here.
E.g. if you normally use

ssh -p1234 -some-other-parameter franzi at ubuntubox.example.com

please use

ssh -vvv -p1234 -some-other-parameter franzi at ubutubox.example.com

for this test.

3) If, in step 1, ssh-add -l did not generate any output at all (no
error messages, but also nothing that would hint at your keyfile being
loaded already), run:

ssh-add # if your keyfile is the default /Users/Franziska/.ssh/id_rsa

or

ssh-add -i /this/is/where/i/store/my/keyfile # for a non-standard one

This will prompt you for your keyfile's passphrase.  Please enter it
when prompted.

Check that your keyfile has been loaded by running

ssh-add -l

again.

Now, start X2GoClient.

In the session configuration, *remove* the path and file name for the
key file.  Make sure that particular field is completely empty.

*Do* check the "Try auto login" box, though.

Then try to connect.

If you can connect that way, it is likely that
a) either something was amiss regarding the file name and path you
specified, or the file permissions
or
b) we have a bug in X2GoClient (or in libssh, actually) that manifests
itself on macOS only.

Although a) seems more likely, I do not want to rule out b).

Please report back with your findings.

Kind regards,
Stefan Baur

-- 
BAUR-ITCS UG (haftungsbeschränkt)
Geschäftsführer: Stefan Baur
Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364
Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243