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