Hey everyone, Any advice on the problem below? I hit it consistently with X2Go Client, but it does not happen with the Pyhoca client. Error: Kex error : no match for method server host key alog: server [ssh-rsa], client [ssh-ed25519]. Client computer:
Server: Linux Mint 17.1 (Ubuntu 14.04.1) running the MATE desktop.
X2Go Server: Server Core: x2goserver (4.0.1.19) x2goagent (3.5.0.31)
Server Extensions: x2goserver-extensions (4.0.1.19) x2goserver-xsession (4.0.1.19)
X2Go Server Add-ons: x2gomatebindings (0.0.1.3)
X2Go Server Features: X2GO_CLIPBOARD_MODES X2GO_LIST_DESKTOPS X2GO_MATEBINDINGS X2GO_MOUNTDIRS X2GO_MOUNT_UNCPATHS X2GO_PUBLISHED_APPLICATIONS X2GO_RUN_EXTENSIONS X2GO_SERVERSIDE_DESKTOPCOMMANDS X2GO_SET_KEYBOARD X2GO_UMOUNTSESSION_ALL X2GO_UMOUNTSESSION_ONLYPATH X2GO_XSESSION
Additional Information: Usually I use X2Go without ssh keys, so just type in my userid & password when connecting to the Linux desktop. This has worked fine. When the problem above started to happen, I tried generating RSA keys on my Windows machine and transferred them to my Linux machine, but this didn't help. I also tried with DSA and also ED22519 keys, but no-go on X2Go. I installed Pyhoca and authenticate using my userid & password. I can then connect to the suspended session that was originally created with the X2Go client. For now I am using the Pyhoca client, but would also like to get the X2Go client working again.
Thanks!
Hello -
Here is a link with some background, which describes two workarounds :
http://permalink.gmane.org/gmane.linux.terminal-server.x2go.user/2368
You would add this to your sshd_config file on the client (Linux) machine, then restart ssh
# KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
I hope this helps.
De : x2go-user-bounces@lists.x2go.org <x2go-user-bounces@lists.x2go.org> de la part de jmmec2014@yahoo.com <jmmec2014@yahoo.com> Envoyé : mardi 14 février 2017 10:30:43 À : x2go-user@lists.x2go.org Objet : [X2Go-User] X2Go Client: Kex error : no match for method server host key alog: server [ssh-rsa], client [ssh-ed25519]
Hey everyone,
Any advice on the problem below? I hit it consistently with X2Go Client, but it does not happen with the Pyhoca client.
Error:
Kex error : no match for method server host key alog: server [ssh-rsa], client [ssh-ed25519].
Client computer:
Windows 8.1 connecting to Linux Mint 17.1 (Ubuntu 14.04.1) running the MATE desktop.
X2Go client software v4.0.5.2. The problem does not happen with the Pyhoca software (I downloaded the latest version).
Server:
Linux Mint 17.1 (Ubuntu 14.04.1) running the MATE desktop.
X2Go Server: Server Core: x2goserver (4.0.1.19) x2goagent (3.5.0.31)
Server Extensions:
x2goserver-extensions (4.0.1.19)
x2goserver-xsession (4.0.1.19)
X2Go Server Add-ons: x2gomatebindings (0.0.1.3)
X2Go Server Features: X2GO_CLIPBOARD_MODES X2GO_LIST_DESKTOPS X2GO_MATEBINDINGS X2GO_MOUNTDIRS X2GO_MOUNT_UNCPATHS X2GO_PUBLISHED_APPLICATIONS X2GO_RUN_EXTENSIONS X2GO_SERVERSIDE_DESKTOPCOMMANDS X2GO_SET_KEYBOARD X2GO_UMOUNTSESSION_ALL X2GO_UMOUNTSESSION_ONLYPATH X2GO_XSESSION
Additional Information:
Usually I use X2Go without ssh keys, so just type in my userid & password when connecting to the Linux desktop. This has worked fine.
When the problem above started to happen, I tried generating RSA keys on my Windows machine and transferred them to my Linux machine, but this didn't help. I also tried with DSA and also ED22519 keys, but no-go on X2Go.
I installed Pyhoca and authenticate using my userid & password. I can then connect to the suspended session that was originally created with the X2Go client.
For now I am using the Pyhoca client, but would also like to get the X2Go client working again.
Thanks!
On 14.02.2017 07:30 PM, jmmec2014@yahoo.com wrote:
Kex error : no match for method server host key alog: server [ssh-rsa], client [ssh-ed25519].
This is odd. Karl's suggestion won't help, as this is not related to kex algorithms.
Instead, your server provides an RSA host key, but the client (in this case libssh for X2Go Client) seems to support ssh-ed25519 only.
Odd, because libssh certainly does support RSA keys. Did you generate the server host keys yourself? Maybe it's too big?
libssh definitely supports RSA keys and it should report that its list as well.
You're not seeing this issue with PyHoca, because PyHoca uses Paramiko, an implementation of SSH in python. The supported features differ based upon the implementation, as you can see (libssh vs. Paramiko in this case.)
Mihai
Thanks Mihai for the info. I don't know why Windows 8.1 was suddenly only supporting ssh-ed25519 and failing to connect to my Linux Mint session with that "kex error". What is even stranger: the problem suddenly went away and I could once again use the x2go client to connect to that session (the same session that I've had running for more than a month - maybe two months by now). At least for now the "kex error" is gone with the X2GO client.
Thanks for explaining why Pyhoca was working. It is good to know that both clients use different ssh libraries in case this problem strikes again.
From: Mihai Moldovan <ionic@ionic.de>
To: jmmec2014@yahoo.com; "x2go-user@lists.x2go.org" <x2go-user@lists.x2go.org> Sent: Thursday, February 23, 2017 5:35 AM Subject: Re: [X2Go-User] X2Go Client: Kex error : no match for method server host key alog: server [ssh-rsa], client [ssh-ed25519]
On 14.02.2017 07:30 PM, jmmec2014@yahoo.com wrote:
Kex error : no match for method server host key alog: server [ssh-rsa], client [ssh-ed25519].
This is odd. Karl's suggestion won't help, as this is not related to kex algorithms.
Instead, your server provides an RSA host key, but the client (in this case libssh for X2Go Client) seems to support ssh-ed25519 only.
Odd, because libssh certainly does support RSA keys. Did you generate the server host keys yourself? Maybe it's too big?
libssh definitely supports RSA keys and it should report that its list as well.
You're not seeing this issue with PyHoca, because PyHoca uses Paramiko, an implementation of SSH in python. The supported features differ based upon the implementation, as you can see (libssh vs. Paramiko in this case.)
Mihai
On 24.02.2017 01:14 AM, jmmec2014@yahoo.com wrote:
I don't know why Windows 8.1 was suddenly only supporting ssh-ed25519 and failing to connect to my Linux Mint session with that "kex error". What is even stranger: the problem suddenly went away and I could once again use the x2go client to connect to that session (the same session that I've had running for more than a month - maybe two months by now). At least for now the "kex error" is gone with the X2GO client.
That's weird... libssh shouldn't behaving differently from one invocation to the other, really. Did you really change nothing server-side?
Mihai
On Redhat derived systems there have been many recent updates to openssh,
many of them disabling known to be insecure protocols.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Sun, 26 Feb 2017, Mihai Moldovan wrote:
Date: Sun, 26 Feb 2017 05:40:47 +0100 From: Mihai Moldovan <ionic@ionic.de> To: jmmec2014@yahoo.com, "x2go-user@lists.x2go.org" <x2go-user@lists.x2go.org> Subject: Re: [X2Go-User] X2Go Client: Kex error : no match for method server host key alog: server [ssh-rsa], client [ssh-ed25519]
On 24.02.2017 01:14 AM, jmmec2014@yahoo.com wrote:
I don't know why Windows 8.1 was suddenly only supporting ssh-ed25519 and failing to connect to my Linux Mint session with that "kex error". What is even stranger: the problem suddenly went away and I could once again use the x2go client to connect to that session (the same session that I've had running for more than a month - maybe two months by now). At least for now the "kex error" is gone with the X2GO client.
That's weird... libssh shouldn't behaving differently from one invocation to the other, really. Did you really change nothing server-side?
Mihai
On 26.02.2017 05:45 AM, Robert Dinse wrote:
On Redhat derived systems there have been many recent updates to openssh,
many of them disabling known to be insecure protocols.
Yes, but the *server* advertised its RSA key (only, which also seems weird, as it should have been also advertising DSA if not disabled and - if DSA were disabled, most likely also ECDSA and ED keys), while the client/libssh only advertised supporting ED-type keys. That's what makes this so wicked.
Mihai
Yes that is odd.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Sun, 26 Feb 2017, Mihai Moldovan wrote:
Date: Sun, 26 Feb 2017 05:58:46 +0100 From: Mihai Moldovan <ionic@ionic.de> To: Robert Dinse <nanook@eskimo.com> Cc: jmmec2014@yahoo.com, "x2go-user@lists.x2go.org" <x2go-user@lists.x2go.org> Subject: Re: [X2Go-User] X2Go Client: Kex error : no match for method server host key alog: server [ssh-rsa], client [ssh-ed25519]
On 26.02.2017 05:45 AM, Robert Dinse wrote:
On Redhat derived systems there have been many recent updates to openssh,
many of them disabling known to be insecure protocols.
Yes, but the *server* advertised its RSA key (only, which also seems weird, as it should have been also advertising DSA if not disabled and - if DSA were disabled, most likely also ECDSA and ED keys), while the client/libssh only advertised supporting ED-type keys. That's what makes this so wicked.
Mihai
On 24.02.2017 01:14 AM, jmmec2014@yahoo.com wrote:
I don't know why Windows 8.1 was suddenly only supporting ssh-ed25519 and failing to connect to my Linux Mint session with that "kex error". What is even stranger: the problem suddenly went away and I could once again use the x2go client to connect to that session (the same session that I've had running for more than a month - maybe two months by now). At least for now the "kex error" is gone with the X2GO client.
Stefan just had the same problem. Then it struck me - he's using DHCP in his network and IP addresses of virtual machines often get reassigned addresses based on which ones are free (hence the addresses are only pseudo-static.)
He tried to connect to a CentOS 5 box and got the same error. The problem was that this exact host was already recorded in his known_hosts file with an ED key
In general a little bit less weird, though, as in his output the server advertised both RSA and DSA keys, like you'd expect of a CentOS 5 machine.
A similar thing probably happened to you.
Mihai
Interesting! It hasn't happened again, but will keep this in mind. Thanks so much...
From: Mihai Moldovan <ionic@ionic.de>
To: jmmec2014@yahoo.com; "x2go-user@lists.x2go.org" <x2go-user@lists.x2go.org> Sent: Monday, February 27, 2017 6:48 AM Subject: Re: [X2Go-User] X2Go Client: Kex error : no match for method server host key alog: server [ssh-rsa], client [ssh-ed25519]
On 24.02.2017 01:14 AM, jmmec2014@yahoo.com wrote:
I don't know why Windows 8.1 was suddenly only supporting ssh-ed25519 and failing to connect to my Linux Mint session with that "kex error". What is even stranger: the problem suddenly went away and I could once again use the x2go client to connect to that session (the same session that I've had running for more than a month - maybe two months by now). At least for now the "kex error" is gone with the X2GO client.
Stefan just had the same problem. Then it struck me - he's using DHCP in his network and IP addresses of virtual machines often get reassigned addresses based on which ones are free (hence the addresses are only pseudo-static.)
He tried to connect to a CentOS 5 box and got the same error. The problem was that this exact host was already recorded in his known_hosts file with an ED key
In general a little bit less weird, though, as in his output the server advertised both RSA and DSA keys, like you'd expect of a CentOS 5 machine.
A similar thing probably happened to you.
Mihai