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