Dear Stefan,
Thank you so much for your help! The output of the ssh -vvv command is the following:
OpenSSH_7.9p1, LibreSSL 2.7.3 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 48: Applying options for * debug1: /etc/ssh/ssh_config line 52: Applying options for * debug2: resolve_canonicalize: hostname 158.39.74.200 is address debug2: ssh_connect_direct debug1: Connecting to 158.39.74.200 [158.39.74.200] port 22. debug1: Connection established. debug1: identity file /Users/Franziska/.ssh/id_rsa type 0 debug1: identity file /Users/Franziska/.ssh/id_rsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to 158.39.74.200:22 as 'ubuntu' debug3: hostkeys_foreach: reading file "/Users/Franziska/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /Users/Franziska/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys from 158.39.74.200 debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib@openssh.com,zlib debug2: compression stoc: none,zlib@openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib@openssh.com debug2: compression stoc: none,zlib@openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: Server host key: ecdsa-sha2-nistp256 SHA256:BiZcKXc8StT9NCf586ued3SKTqAmlNksqCuKVg/GeTI debug3: hostkeys_foreach: reading file "/Users/Franziska/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /Users/Franziska/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys from 158.39.74.200 debug1: Host '158.39.74.200' is known and matches the ECDSA host key. debug1: Found key in /Users/Franziska/.ssh/known_hosts:2 debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug1: SSH2_MSG_NEWKEYS received debug2: set_newkeys: mode 0 debug1: rekey after 134217728 blocks debug1: Will attempt key: /Users/Franziska/.ssh/id_rsa RSA SHA256:NUovFss0piG5DYEfmAcGkMQtWT3+YWgw8j3LGFgUsRE explicit debug2: pubkey_prepare: done debug3: send packet: type 5 debug3: receive packet: type 7 debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /Users/Franziska/.ssh/id_rsa RSA SHA256:NUovFss0piG5DYEfmAcGkMQtWT3+YWgw8j3LGFgUsRE explicit debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: /Users/Franziska/.ssh/id_rsa RSA SHA256:NUovFss0piG5DYEfmAcGkMQtWT3+YWgw8j3LGFgUsRE explicit debug3: sign_and_send_pubkey: RSA SHA256:NUovFss0piG5DYEfmAcGkMQtWT3+YWgw8j3LGFgUsRE debug3: sign_and_send_pubkey: signing using rsa-sha2-512 debug3: send packet: type 50 debug3: receive packet: type 52 debug1: Authentication succeeded (publickey). Authenticated to 158.39.74.200 ([158.39.74.200]:22). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting no-more-sessions@openssh.com debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: network debug3: receive packet: type 80 debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug3: receive packet: type 91 debug2: channel_input_open_confirmation: channel 0: callback start debug2: fd 3 setting TCP_NODELAY debug3: ssh_packet_set_tos: set IP_TOS 0x48 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug3: send packet: type 98 debug1: Sending environment. debug3: Ignored env TERM_PROGRAM debug3: Ignored env SHELL debug3: Ignored env TERM debug3: Ignored env TMPDIR debug3: Ignored env CONDA_SHLVL debug3: Ignored env FSLMULTIFILEQUIT debug3: Ignored env Apple_PubSub_Socket_Render debug3: Ignored env CONDA_PROMPT_MODIFIER debug3: Ignored env TERM_PROGRAM_VERSION debug3: Ignored env TERM_SESSION_ID debug3: Ignored env USER debug3: Ignored env FSLGECUDAQ debug3: Ignored env CONDA_EXE debug3: Ignored env SSH_AUTH_SOCK debug3: Ignored env _CE_CONDA debug3: Ignored env PATH debug3: Ignored env CONDA_PREFIX debug3: Ignored env PWD debug1: Sending env LANG = de_DE.UTF-8 debug2: channel 0: request env confirm 0 debug3: send packet: type 98 debug3: Ignored env FSLTCLSH debug3: Ignored env FSLMACHINELIST debug3: Ignored env XPC_FLAGS debug3: Ignored env FSLREMOTECALL debug3: Ignored env FSLWISH debug3: Ignored env _CE_M debug3: Ignored env XPC_SERVICE_NAME debug3: Ignored env SHLVL debug3: Ignored env HOME debug3: Ignored env CONDA_PYTHON_EXE debug3: Ignored env LOGNAME debug3: Ignored env FSLDIR debug3: Ignored env CONDA_DEFAULT_ENV debug3: Ignored env DISPLAY debug3: Ignored env FSLLOCKDIR debug3: Ignored env FSLOUTPUTTYPE debug3: Ignored env _ debug3: Ignored env __CF_USER_TEXT_ENCODING debug2: channel 0: request shell confirm 1 debug3: send packet: type 98 debug2: channel_input_open_confirmation: channel 0: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-64-generic x86_64)
- Documentation: https://help.ubuntu.com
- Management: https://landscape.canonical.com
- Support: https://ubuntu.com/advantage
System information as of Thu Nov 7 07:32:33 UTC 2019
System load: 0.1 Processes: 129 Usage of /: 35.0% of 19.21GB Users logged in: 0 Memory usage: 2% IP address for ens3: 158.39.74.200 Swap usage: 0%
Kata Containers are now fully integrated in Charmed Kubernetes 1.16! Yes, charms take the Krazy out of K8s Kata Kluster Konstruction.
Canonical Livepatch is available for installation.
- Reduce system reboots and improve kernel security. Activate at: https://ubuntu.com/livepatch
12 packages can be updated. 0 updates are security updates.
*** System restart required *** Last login: Wed Nov 6 10:44:19 2019 from 84.215.109.238
The first time I ran ssh -add -l, I got "The agent has no identities." but after running ssh -add again like you described, it worked and I was able to connect via x2go. However, until now (I waited for 5-10 minutes), I only see a black window instead of a desktop and the terminal of my server gives me this:
debug2: client_check_window_change: changed debug2: channel 0: request window-change confirm 0 debug3: send packet: type 98
The details of the session say this:
NXPROXY - Version 3.5.99.14
Copyright (c) 2001, 2011 NoMachine (http://www.nomachine.com) Copyright (c) 2008-2014 Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> Copyright (c) 2014-2016 Ulrich Sibiller <uli42@gmx.de> Copyright (c) 2014-2016 Mihai Moldovan <ionic@ionic.de> Copyright (c) 2011-2016 Mike Gabriel <mike.gabriel@das-netzwerkteam.de> Copyright (c) 2015-2016 Qindel Group (http://www.qindel.com)
NXCOMP, NX protocol compression and NX extensions to this software are copyright of the aforementioned persons and companies.
Redistribution and use of the present software is allowed according to terms specified in the file LICENSE.nxcomp which comes in the source distribution.
All rights reserved.
NOTE: This software has received contributions from various other contributors, only the core maintainers and supporters are listed as copyright holders. Please contact us, if you feel you should be listed as copyright holder, as well.
NX protocol compression is derived from DXPC project.
Copyright (c) 1995,1996 Brian Pane Copyright (c) 1996,1997 Zachary Vonler and Brian Pane Copyright (c) 1999 Kevin Vigor and Brian Pane Copyright (c) 2000,2003 Gian Filippo Pinzari and Brian Pane
All rights reserved.
See https://github.com/ArcticaProject/nx-libs for more information.
Info: Proxy running in server mode with pid '10787'. Session: Starting session at 'Thu Nov 7 08:35:00 2019'. Info: Using errors file '/Users/Franziska/.x2go/S-ubuntu-50-1573112097_stDKDE_dp32/sessions'. Info: Using stats file '/Users/Franziska/.x2go/S-50/stats'. Loop: WARNING! Overriding auxiliary X11 port with new value '1'. Warning: Overriding auxiliary X11 port with new value '1'. Info: Connecting to remote host 'localhost:32015'. Info: Connected to remote proxy on FD#11. Info: Connection with remote proxy completed. Loop: WARNING! Unrecognized session type 'unix-kde-depth_32'. Assuming agent session. Warning: Unrecognized session type 'unix-kde-depth_32'. Assuming agent session. Info: Using ADSL link parameters 1408/24/1/0. Info: Using cache parameters 4/4096KB/8192KB/8192KB. Info: Using pack method '16m-jpeg-9' with session 'unix-kde-depth_32'. Info: Using ZLIB data compression 1/1/32. Info: Using ZLIB stream compression 4/4. Info: No suitable cache file found. Info: Forwarding X11 connections to display '/private/tmp/com.apple.launchd.Um7nD5Bl6q/org.macosforge.xquartz:0'. Info: Forwarding auxiliary X11 connections to display '/private/tmp/com.apple.launchd.Um7nD5Bl6q/org.macosforge.xquartz:0'. Session: Session started at 'Thu Nov 7 08:35:00 2019'. Info: Established X server connection. Info: Using shared memory parameters 0/0K. Session: Terminating session at 'Thu Nov 7 08:48:20 2019'. Session: Session terminated at 'Thu Nov 7 08:48:20 2019'.
I tried again, and the same thing happens, it connects but the desktop doesn't load. Before I installed x2go, I did install the KDE desktop on my server (at least I thought I did, but maybe something went wrong there).
Kind regards, Franziska Goltz
On 2019-11-06 14:06, Stefan Baur wrote:
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:
- 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.
- 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@ubuntubox.example.com
please use
ssh -vvv -p1234 -some-other-parameter franzi@ubutubox.example.com
for this test.
- 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