tdaff / remote_ikernel

All your Jupyter kernels, on all your machines, in one place.
https://pypi.org/project/remote_ikernel/
BSD 2-Clause "Simplified" License
17 stars 14 forks source link

False alert with 'Intensive SSH Scanning' #13

Closed tdaff closed 8 years ago

tdaff commented 8 years ago

Original report by Anonymous.


I tried out using a ssh Remote kernel on a host serviced from 3rox.net (Pittsburgh Super-computer center).

After crashing the kernel a few times, my access to the entire 3rox network was blocked and I received an email from the security team claiming my host has been 'intensive SSH Scanning' over an external network, and threating to remove my computer from the network.

Thus using remote_ikernel over the WAN has risks. This needs to be addressed. At least the users shall be warned until a fix or workaround is implemented.

I will post an update when I hear back from the network admins at PSC.

tdaff commented 8 years ago

Original comment by Feng Yu (Bitbucket: rainwoodman, GitHub: rainwoodman).


Hmm. I forgot to login.

tdaff commented 8 years ago

Original comment by Feng Yu (Bitbucket: rainwoodman, GitHub: rainwoodman).


One possible way to reduce the number of ssh sessions is to use something similar to

https://github.com/paramiko/paramiko/blob/master/demos/forward.py

to open multiple port forwardings in the same session.

But it is yet unclear if this will trigger the network defense system as well.

tdaff commented 8 years ago

Original comment by Tom Daff (Bitbucket: tdaff, GitHub: tdaff).


Hi Yu,

Sorry for the issues you've experienced. Often convenience hacks like this are a thorn in the side of the sysadmins.

The most recent version already consolidates all of the SSH tunnels into one connection (see 1c65df3), I just hadn't put it on pypi yet (it's there now). If you make sure that you have version 0.4.1 each kernel will now create 1 SSH connection for the kernel and one SSH connection for all the tunnels (rather than 5 that keep respawning).

I'm concerned this may not be enough. The most recent updates can now tunnel across the internet deep into firewalled clusters, and as you say, this can be risky. I'd be interested to hear what your admins say. Feel free to message me directly if there is sensitive info and I'll be happy to get in touch with them directly if necessary.

In the meantime, I'll add some warnings in the README and interface. Security is obviously very important.

tdaff commented 8 years ago

Original comment by Feng Yu (Bitbucket: rainwoodman, GitHub: rainwoodman).


Oh, btw. What about setting up a SOCKS proxy via SSH, that is maintained by the notebook server? [with a button somewhere to turn it on or off.] It may be more involved but it does seem to be more prudent to false alerts like this..

tdaff commented 8 years ago

Original comment by Feng Yu (Bitbucket: rainwoodman, GitHub: rainwoodman).


The security admin suggested me to switch to the latest version to minimize the possibility of a false alert.

Were you aware of the -f -N, and -M -O -S options? This seems to be able to allow one connection to the entire host (multiplexing) The OpenSSH wikibook has plenty of examples on this:

https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing#Advantages_of_Multiplexing

But there will be added complexity managing the life cycle of a multiplexing master..

tdaff commented 8 years ago

Original comment by Feng Yu (Bitbucket: rainwoodman, GitHub: rainwoodman).


Any how, since the original issue is 'resolved', shall we close this and move the talk about multiplexing to another thread?

tdaff commented 8 years ago

Original comment by Tom Daff (Bitbucket: tdaff, GitHub: tdaff).


Fewer connections. Discussion moved to issue #18