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)
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.
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
Am 08.11.19 um 09:58 schrieb Franziska Goltz:
[...]
debug1: Server accepts key: /Users/Franziska/.ssh/id_rsa RSA
So your key is in the default location and has the default name. Good.
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.
So this means either you had a typo when you specified the keyfile, or keyfile authentication, but not ssh-agent authentication, is currently broken on our macOS client.
If you want to cross-check, edit the session settings again, and enter
/Users/Franziska/.ssh/id_rsa
as the file name for the keyfile.
Then (this is important) *un-check* the "Try auto login" box again.
Next time you try to connect by clicking on the session tile, you should see a pop-up window asking for the passphrase.
If you can't log in that way, please let us know so we can start further investigations as to what might be going wrong.
Please also note that there is some GUI way of adding your keyfile to the agent, so you don't have to use the ssh-add command on the command line every time. However, since I am not a Mac user myself, I do not know what the proper tool for this is on a Mac.
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:
[...]
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).
Sadly, KDE5/Plasma is a Desktop environment that isn't really a good choice for remote desktop use. The only worse contender is Gnome3 - with X2Go stable, it doesn't work at all, while with KDE5/Plasma, results vary from distribution to distribution.
Do you really need a full remote desktop, or would it be good enough for you to be able to start remote applications in your local desktop?
If you need a full desktop, I would suggest checking out LXDE, LXQt, XFCE or MATE. All these are known to work with X2Go.
If you absolutely need to run KDE5/Plasma, and you can't move away from Ubuntu on the server side (I hear KDE5/Plasma is "kind of" working on Debian Buster), then I am afraid you will need to get your hands dirty - there's a beta version of X2GoServer that you could install, and you'd also need the corresponding beta version of X2GoClient on your Mac (and I'm not even sure if we have macOS beta builds for this particular feature yet). This isn't for the faint of heart, so let me know if you want to continue down that route.
If running remote applications is fine, then I would suggest you change the following settings in X2GoClient:
Click "Options" in the menu bar, then "Settings". The first tab, "General", should have all the options you need. Check the "Display Icon in System Tray" box, this un-greys the four checkboxes below it, check all of them as well, click "OK".
Then, back in the session configuration, change the session type from KDE to "Published Applications".
After that, once X2GoClient is running and has an active session, published apps can be accessed by right-clicking the tray icon and selecting the name of the session. A left click un-hides the X2GoClient window.
Note that on macOS, at least in earlier client builds, left click and right click did the same (which can be a bit annoying), so it would hide/unhide the client window along with showing the published application list. Not sure if that has now been fixed, as, again, I am not a Mac user myself.
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