Is ssh private key remote access broken in CUDA 8.0 nsight?

I installed CUDA8.0 in Fedora 25 on my laptop and home server. I got the gcc 4.9 installed in both places. I can get my project compiled fine without issues.

But once I imported it to nsight on my laptop and tried to remote execute/debug through ssh public/private key connection, it failed.

I’m not sure if it is related to issue ( Because I did see the error in my home server sshd log: DH GEX group out of range

Anyone encounter remote access problem in 8.0?

Yes, I’m pretty sure nsight is broken in ssh. The remote system explorer module is OLD. Why can’t NVIDIA based on latest eclipse?

In any case, there is downside in my workaround below:

In sshd_config, add:

TODO fix me later

KexAlgorithms +diffie-hellman-group1-sha1

In nsight, ssh key exchange choose diffie-hellman-group1-sha1 only.

This sucks in term of security. It supposed to be patched 2/3 years ago. I doubt if anyone would risk its server to work around this.
Good luck NVIDIA.

Hi, rickyzhang

referred Key exchange methods can be selected using the Nsight preference pages.

From Nsight main menu, open Windows ->Preferences -> General -> Network connections -> SSH2

On the right side tab, go to “Key Exchange Methods” tab and select the preferred method and move it to the top using the “Up” button.

Thanks. But I knew the workaround in my post #2.

The problem is that NVIDIA should base their IDE on the latest eclipse. Who on earth will risk their server this way in production? I’m pretty sure my admin won’t allow me to tamper ssh server this way.

I just wanted to add some info here. When using ssh from my development host to L4T R24.2.1 of a Jetson TX1 on command line things work fine (host ssh is modern). When using nsight it looks like the ssh software is built into eclipse and is not capable of being configured as to key exchange algorithms (and current L4T will not allow what is considered insecure). It doesn’t matter if I import a working key from “~/.ssh/id_rsa” since it isn’t the key which fails…it’s the key exchange. This also means password based login cannot work because exchange is involved even when a password is used.

Here’s the “/var/log/auth.log” line which shows up on the Jetson as the key exchange is rejected:

Feb 10 11:39:13 x1 sshd[2163]: fatal: mm_answer_moduli: bad parameters: 2048 2048 1024

Does anyone here know how to configure key exchange within nsight, or else to force nsight to use the system’s ssh instead of the ssh built into nsight (the system ssh works great and is not out of date)? Without this nsight can’t be used with remote L4T development…I’m not interested in downgrading key exchange (this would have an effect beyond just nsight since this is part of both ends of the connection).

Hi, linuxdev

For the error log you printed, I have met also before.
And the workaround is below

ssh issue seems to be related to Openssh which uses “Key Exchange Algorithms”
Try limiting “Key Excahnge Algoritm” to legacy algorithm. Follow the steps given here This has solved the issue for many.

I’ve not seen any way to enable the older key exchange without breaking something else (I admit I didn’t try too hard though…I’m not interested in downgrading my host machine’s security for other purposes which I believe would happen). I did briefly experiment with adding other key exchange algorithms, but this never succeeded (if this had succeeded I wouldn’t have kept it anyway…my Fedora host also talks to the outside world and needs security).

The so called legacy key exchange algorithm is deemed to be unsafe. If you server didn’t open to public network or is not managed by admin at work, you should be fine to find the workaround. But most of the time, it is not the case.

Eclipse’s dependency is mainly on Java version. JDK8 and JDK7 are quite common in major Linux distro. I don’t see the reason why NVIDIA can’t base their nsight on recent eclipse.

I require my ssh between machines physically separate across the public internet, as well as private and semi-private networks. I could never expose the outside world interface to weak exchanges (on at least one of the outside world machines I’ve seen hits about every 30 seconds for all kinds of exploits non-stop for the entire life of the machine). This is a big part of why I can’t use the workaround…I’ve not seen a way to enable weak key exchanges for some interfaces, but not others, and firewalls cannot distinguish key exchange of weak versus strong exchanges, so firewalls won’t help once key exchange is watered down…it becomes a problem for all ssh traffic.

Hi, rickyzhang and linuxdev

We plan to relese Nsight Eclipse plugins version with CUDA 9.0 that can be installed on Eclipse 4.5.

That will resolve the issues with Eclipse 4.4.

Hope this can solve your problem.

Sorry for the incovinience for now.