[IPython-User] connecting to remote kernel in 0.11

MinRK benjaminrk@gmail....
Sat Aug 6 13:16:24 CDT 2011

On Sat, Aug 6, 2011 at 09:55, neil rabinowitz <
neil.rabinowitz@merton.ox.ac.uk> wrote:

> I'm still trying to figure out this local vs remote kernel story. Aside
> from my ssh question below, can someone offer an explanation/example of how
> i set up and connect to a remote kernel (on linux), even if unsecured? The
> most I can find is from the ipython_qtconsole_config.py file:
> # Set the kernel's IP address [default localhost]. If the IP address
> is
> # something other than localhost, then Consoles on other machines will be
> able
> # to connect to the Kernel, so be
> careful!
> # c.IPythonQtConsoleApp.ip = ''
> If I try to specify my network-facing interface IP with a flag, e.g.:
> ipython qtconsole --ip=192.168.X.X
> then it fails, printing a stack and the following:
> RuntimeError: Can only launch a kernel on a local interface. Make sure that
> the '*_address' attributes are configured properly. Currently valid
> addresses are: ['', '', '', '']

This would suggest that our code that determines the available IPs on your
system isn't working properly.  We should probably relax this check, and
trust the user to know their own IP.

What do you get with:

import socket
hostname = socket.gethostname()


> Following the documentation that opens up the kernel to all
> interfaces, I try launching ipython with the ip tag set to, which
> does indeed launch a console. However, I can't then seem to connect to this
> instance anyway I try. The usual method (launching a new instance with the
> "--existing ..." flags) brings up a qtconsole, displaying the usual headers,
> but no prompt ever appears. The same is true if I append the extra flags to
> the second qtconsole of --ip= or --ip= and so on -- just a
> promptless console.

That should definitely work, so it's presumably some kind of bug, but I
can't think of what it would be.

ipython qtconsole --ip=
# copy '--existing...'

then connect with:

ipython qtconsole --ip=192.168.X.Y <paste>
# or if you are on the same machine:
ipython qtconsole --ip= <paste>

You can't connect to, because it's a bind alias for listening on all
interfaces, not a real address.  Since you are on localhost, you might also
try loopback interfaces when connecting, to see if maybe the issue confusing
IPython's guess about local IPs is affecting how zeromq interprets

> Is there a simple syntactical trick I'm missing, or is my use case is not
> what this system is designed for?

Shouldn't be, there just appears to be something different about your system
that we don't handle properly.

As for SSH, you need to set up tunnels.  The parallel code will try to set
up these tunnels for you, but the KernelManager used in the qt code doesn't
use this yet, and you have to set them up yourself.

Let's say I start a qtconsole on machine `server`:

server > ipython qtconsole
[IPKernelApp] To connect another client to this kernel, use:
[IPKernelApp] --existing --shell=55460 --iopub=55461 --stdin=55462

Which is now listening on localhost by default.

Now on machine `client`, I will need to set up tunnels to loopback on

client > ssh server -f -N -L 55460:
client > ssh server -f -N -L 55461:
client > ssh server -f -N -L 55462:
client > ssh server -f -N -L 55463:

(the `-f -N` just mean "run in the background, and don't to anything but

That is to say, if *on client* I now try to connect to localhost:55460, the
connection will be forwarded to localhost:55460 *on server*, etc.
So now I can just copy-paste the connection line to the client:

client > ipython qtconsole --existing --shell=55460 --iopub=55461
--stdin=55462 --hb=55463

and I will have a qtconsole that is using the same kernel as the one on the

The one extra step is that you might want to connect to a machine that is
not visible from client.  Let's say there is now a machine `login` that has
direct access to server, and login is visible on the internet, but server is

The change on server is to listen on an external IP, either or a
specific interface:

server > ipython qtconsole --ip=
[IPKernelApp] To connect another client to this kernel, use:
[IPKernelApp] --existing --shell=55460 --iopub=55461 --stdin=55462

Now you need to tunnel slightly differently, because you want local ports on
client to point to `server` via `login`, rather than `` via

client > ssh login -f -N -L 55460:server:55460
client > ssh login -f -N -L 55461:server:55461
client > ssh login -f -N -L 55462:server:55462
client > ssh login -f -N -L 55463:server:55463

That is, when client asks for these ports on localhost, they will actually
get the ports on server, using login as an intermediary.

Now, once again, you can connect the client to what it thinks is a local

client > ipython qtconsole --existing --shell=55460 --iopub=55461
--stdin=55462 --hb=55463

I hope that clears things up a little bit.  I know setting up multiple ssh
tunnels is not the most obvious process.


> Thanks
> Neil
> On Thu, Aug 4, 2011 at 9:48 PM, neil rabinowitz <
> neil.rabinowitz@merton.ox.ac.uk> wrote:
>> hello
>> firstly, much credit is due to all who have contributed to the 0.11
>> release. i've been migrating the last couple of days, and i'm impressed with
>> all you've done.
>> i'm trying to have a play around with the client/kernel architecture. in
>> particular, i usually run instances of python on my lab server, which i
>> access remotely via ssh (e.g. from elsewhere in the lab or at home). i'm
>> wondering what is the standard protocol for securely connecting a qt console
>> client to a remote kernel -- i can't seem to find appropriate documentation.
>> could someone please point me in the appropriate direction?
>> best
>> neil
> _______________________________________________
> IPython-User mailing list
> IPython-User@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/ipython-user/attachments/20110806/c3ce4f21/attachment.html 

More information about the IPython-User mailing list