[9fans] ssh2 (at least the legacy version) seems incompatible with openssh-6.7

[9fans] ssh2 (at least the legacy version) seems incompatible with openssh-6.7

[Ingo Krabbe]

Hi,

the netssh key exchange seems to be incompatible with openssh-6.7.

I installed a new version of openssh on a gentoo host recently, that automatically came in as a stable update package for a gentoo-amd64 system:

	OpenSSH_6.7p1-hpn14v5, OpenSSL 1.0.1k 8 Jan 2015

When calling this system with a plan9 (legacy) ssh2, the netssh process does not provide any data in /net/ssh/keys. The read at /sys/src/cmd/ssh2/ssh2.c:/^keyproc/+19, reads n=0 bytes when connecting to the version of OpenSSH above.

I don't understand enough of the netssh keyfile infrastructure to debug this logistic behaviour of /net/ssh/keys.

A downgrade to

	OpenSSH_6.6p1-hpn14v4, OpenSSL 1.0.1k 8 Jan 2015

gives me ssh access to the gentoo system again.

If I find out more, I will post a followup. But maybe it would be helpfull if someone with more insight into netssh tries to resolve this bug.

regards,

ingo krabbe

Re: [9fans] ssh2 (at least the legacy version) seems incompatible with

[Ingo Krabbe]

ok, i found some more diagnostic messages in /sys/log/sshdebug:

	p9 Jan 21 10:55:48 netssh: client user <nil>@192.168.1.12 id 0 id string `SSH-2.0-OpenSSH_6.7p1-hpn14v5
	p9 Jan 21 10:55:48 netssh: client user <nil>@192.168.1.12 id 0 sent KEX algs: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
	…
	p9 Jan 21 10:55:49 netssh: client user <nil>@192.168.1.12 id 0 using diffie-hellman-group14-sha1 Kex algorithm and ssh-rsa PKA

in contrast to:
	p9 Jan 21 10:57:31 netssh: client user <nil>@192.168.122.6 id 0 id string `SSH-2.0-OpenSSH_6.6.1p1-hpn14v5	
	…
	p9 Jan 21 10:57:31 netssh: client user <nil>@192.168.122.6 id 0 using diffie-hellman-group1-sha1 Kex algorithm and ssh-rsa PKA

The problem might be that `dh.c` has an empty implementation of `dh_client142`

	Kex dh1sha1 = {
		"diffie-hellman-group1-sha1",
		dh_server1,
		dh_client11,
		dh_client12
	};
	
	Kex dh14sha1 = {
		"diffie-hellman-group14-sha1",
		dh_server14,
		dh_client141,
		dh_client142
	};


> Hi,
> 
> the netssh key exchange seems to be incompatible with openssh-6.7. 
> 
> I installed a new version of openssh on a gentoo host recently, that automatically came in as a stable update package for a gentoo-amd64 system:
> 
> 	OpenSSH_6.7p1-hpn14v5, OpenSSL 1.0.1k 8 Jan 2015
> 
> When calling this system with a plan9 (legacy) ssh2, the netssh process does not provide any data in /net/ssh/keys. The read at /sys/src/cmd/ssh2/ssh2.c:/^keyproc/+19, reads n=0 bytes when connecting to the version of OpenSSH above.
> 
> I don't understand enough of the netssh keyfile infrastructure to debug this logistic behaviour of /net/ssh/keys.
> 
> A downgrade to
> 
> 	OpenSSH_6.6p1-hpn14v4, OpenSSL 1.0.1k 8 Jan 2015
> 
> gives me ssh access to the gentoo system again.
> 
> If I find out more, I will post a followup. But maybe it would be helpfull if someone with more insight into netssh tries to resolve this bug.
> 
> regards,
> 
> ingo krabbe

Re: [9fans] ssh2 (at least the legacy version) seems incompatible

[Ingo Krabbe]

Actually openssh-6.7 disabled some "insecure" key exchange algorithms and ciphers and the pln9 netssh command seems to offer some key exchange that it does not support fully.

To allow communication with openssh-6.7 servers, as used to with <=openssh-6.6 servers, it seems most convenient to me, to setup /etc/ssh/sshd_config of the openssh server to allow the "insecure" algorithms that are wiped out of the default algorithms the openssh servers offer.

The sshd_config lines that allow the needed algorithms and honour the defaults of the new version of the openssh-6.7 server (as described on the manual page) are:

# Ciphers and keying
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc
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-group1-sha1

regards,

ingo

> ok, i found some more diagnostic messages in /sys/log/sshdebug:
> 
> 	p9 Jan 21 10:55:48 netssh: client user <nil>@192.168.1.12 id 0 id string `SSH-2.0-OpenSSH_6.7p1-hpn14v5
> 	p9 Jan 21 10:55:48 netssh: client user <nil>@192.168.1.12 id 0 sent KEX algs: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
> 	…
> 	p9 Jan 21 10:55:49 netssh: client user <nil>@192.168.1.12 id 0 using diffie-hellman-group14-sha1 Kex algorithm and ssh-rsa PKA
> 
> in contrast to:
> 	p9 Jan 21 10:57:31 netssh: client user <nil>@192.168.122.6 id 0 id string `SSH-2.0-OpenSSH_6.6.1p1-hpn14v5	
> 	…
> 	p9 Jan 21 10:57:31 netssh: client user <nil>@192.168.122.6 id 0 using diffie-hellman-group1-sha1 Kex algorithm and ssh-rsa PKA
> 
> The problem might be that `dh.c` has an empty implementation of `dh_client142`
> 
> 	Kex dh1sha1 = {
> 		"diffie-hellman-group1-sha1",
> 		dh_server1,
> 		dh_client11,
> 		dh_client12
> 	};
> 	
> 	Kex dh14sha1 = {
> 		"diffie-hellman-group14-sha1",
> 		dh_server14,
> 		dh_client141,
> 		dh_client142
> 	};
> 
> 
>> Hi,
>> 
>> the netssh key exchange seems to be incompatible with openssh-6.7. 
>> 
>> I installed a new version of openssh on a gentoo host recently, that automatically came in as a stable update package for a gentoo-amd64 system:
>> 
>> 	OpenSSH_6.7p1-hpn14v5, OpenSSL 1.0.1k 8 Jan 2015
>> 
>> When calling this system with a plan9 (legacy) ssh2, the netssh process does not provide any data in /net/ssh/keys. The read at /sys/src/cmd/ssh2/ssh2.c:/^keyproc/+19, reads n=0 bytes when connecting to the version of OpenSSH above.
>> 
>> I don't understand enough of the netssh keyfile infrastructure to debug this logistic behaviour of /net/ssh/keys.
>> 
>> A downgrade to
>> 
>> 	OpenSSH_6.6p1-hpn14v4, OpenSSL 1.0.1k 8 Jan 2015
>> 
>> gives me ssh access to the gentoo system again.
>> 
>> If I find out more, I will post a followup. But maybe it would be helpfull if someone with more insight into netssh tries to resolve this bug.
>> 
>> regards,
>> 
>> ingo krabbe

Re: [9fans] ssh2 (at least the legacy version) seems incompatible with

[Brian L. Stuart]

> ok, i found some more diagnostic messages in /sys/log/sshdebug:
> ...
> The problem might be that `dh.c` has an empty implementation of `dh_client142`
> ...

Ingo,
I must admit to being the guilty party for the SSHv2 implementation.
Though Geoff gets credit for cleaning up what was some of my
uglier code.  It's been over a year since I looked at any of it and
probably closer to 3 years since touching the crypto part.  However,
I'll take a look and see if I can get an implementation of the group 14
stuff in place, or at least not have it advertise something it doesn't
do.

BLS