Run notebook without requesting for stupid token

[rornor]

jupyter notebook --help does not show me such option and I dont want to copy paste tokens between devices on my local network.

How can I disable token requirement?

[Carreau]

jupyter notebook --help does not show me such option and I dont want to copy paste tokens between devices on my local network.

How can I disable token requirement?

Set up a password:

http://jupyter-notebook.readthedocs.io/en/latest/public_server.html

without requesting for stupid token

It's not stupid, it's to prevent random website you visit from executing code on your machine.

[Carreau]

Oh, and :

Token authentication is enabled. You need to open the notebook server with its first-time login token in the URL, or enable a password in order to gain access

So that's already in the middle of the explanations.

[JoshuaC3]

What if you cannot get the token, say, if it running as a service?

[takluyver]

Depending on how it's set up, you may be able to get the token by running jupyter notebook list. Otherwise, the same advice about enabling a password still applies.

[libphy]

I'm running jupyter using ssh tunneling. I feel too that the token request by default is stupid. When I run browserless jupyter on the server as background and connect from a remote, it's impossible to see the token from the remote.

[takluyver]

Sorry, we know it's a pain, but the potential security issues that were highlighted were bad enough that we couldn't leave authentication off by default.

We have tried to:

• Provide more ways to get the token:
  • jupyter notebook list in a terminal
  • (From 5.1): If you're authenticated in one browser, right click the Jupyter logo and copy the link to authenticate in another browser.
• Make it easier to set a password, with jupyter notebook password. Setting a password replaces the token authentication.

[woodrujm]

Neither "jupyter notebook password" nor "from notebook.auth import passwd" nor copying the token from "jupyter notebook list" work for me. This is very stupid.

[woodrujm]

(with docker for tensor flow)

[takluyver]

Calling stuff 'stupid' does not make us more keen to help you work these problems out.

[libphy]

@takluyver Thanks, setting a password satisfied my need.

[Carreau]

One thing that could be helpful (if one of you want to contribute), is to help having a UI element to set a password. We have most of the tools in tools/secure_notebook.py but it is not tested enough, probably miss some error handling, links in the docs and then a better CLI tool, and/or UI in the notebook to set-up a password once you've logged in once.

[RubenS02]

If you do not care about the security of the server, you can first create a jupyer config file with:
cd ~/.jupyter
jupyter notebook --generate-config
Then set the c.NotebookApp.token parameter to an empty string in the configuration file created
c.NotebookApp.token = ''
As said in comment, Setting to an empty string disables authentication altogether, which is NOT RECOMMENDED.

[ArieTwigt]

I had the same issue. The three minor actions that worked for me:

1. Disable/empty the caches of the browser (Safari in my case);

2. With the tunneling, check if the port of your local machine is already in use. Otherwise use another port for your local machine, like 8001:

   ssh -L 8001:localhost:8888 yourname@your_server_ip
   

3. Check the port number to insert in the browser --> 8000 (or 8001) instead of 8888 which is indicated by the command line.

From these actions, I think checking the caching by the browser was the most crucial.

Good luck

[bosr]

To get rid of the password or token programmatically, you can also provide a --NotebookApp.token argument to Jupyter:

jupyter notebook --NotebookApp.token=''

This is bad practice, as aptly reminded above by the owners, but can be useful in specific cases.

[Carreau]

You can also do jupyter notebook password as pointed before, and create an empty password. As you said it is a really bad idea.

The next version of the notebook should allow you to setup a password directly on the login page. So at first launch it will ask you for your token and optionally a new password. Then you're set.

[kurtbrose]

Sorry, we know it's a pain, but the potential security issues that were highlighted were bad enough that we couldn't leave authentication off by default.

We have tried to:

Provide more ways to get the token:
jupyter notebook list in a terminal
(From 5.1): If you're authenticated in one browser, right click the Jupyter logo and copy the link to authenticate in another browser.
Make it easier to set a password, with jupyter notebook password. Setting a password replaces the token authentication.

That's interesting -- does anybody know if there is a thread about what the security issues are? 90% of the time I run jupyter as a persistent REPL / scratch pad that is not accessible outside of the one machine. Most security issues I can think of involve some kind of network access. I guess there is still potentially a privilege escalation on the current machine (a process running as a low-privilege user is able to curl to localhost:8888 and execute arbitrary code as your user). However, that seems a bit attenuated?

(I am fine with the current state of things, just curious to understand the security side of things here.)

[Carreau]

You can see one of our blog post

You are spot on on the actual security issues, and while there is no definite public case of that kind of things having happen, we've heard of cases where security features were disabled because of other security layers were deemed enough.

It may even be possible to get access to a localhost-only listening notebook by visiting websites and using localhost DNS rebinding attacks. I'm not going to pretend I understand that, but better safe than sorry.

[takluyver]

There's the issue about one user running code as another, as you pointed out.

But the notebook is also accessible from the browser, which runs code from many untrusted websites. The browser should stop evil.com from making requests to Jupyter running on localhost, but it's a very complicated system. A technique was pointed out to us (#1830) which might let an attacker avoid the normal restrictions and send requests to localhost. I'm not entirely sure whether that attack would work against Jupyter, but it looks like it could get close, at least. That was when we decided that a bit more security by default was necessary.

[Khalilsqu]

i gave up using linux windows subsystem because of this token issue.

cant even use spyder-notebook or pycharm-notebook.

not sure why yet to type yes after pressing Ctrl+c shutting down kernel, just close it without additional confirmation as the case is with windows

[sem-geologist]

only that setting password just not works. This is bizzare. I just wanted to demonstrate how nice and convenient jupyter is... and well it is stupid... another potential users scared away. Good work!

[takluyver]

Could you be more specific? It's hard to debug 'just not works'.

[Carreau]

I understand your frustration when things don't work as expected, but please pay attention to your language. We spend lots of time and work to make things as easy as possible while still secure, and it personally hurt when I spent a week implementing the new screen to simplify setting password without having to reach for the command line. We unfortunately don't have access to infinite resources, and sometime we miss edge cases. We would be happy to work with you to figure out why it did not work for you, and how to make sure it does not affect other people.

I would suggest and read about DNS rebinding: https://bugs.chromium.org/p/project-zero/issues/detail?id=1447
https://arstechnica.com/information-technology/2018/01/bittorrent-users-beware-flaw-lets-hackers-control-your-computer/

Without token or password, you would be vulnerable to local code execution on your machine by just visiting a website.

If you want even more convenience, I would suggest also trying https://nteract.io/, which is a native electron app that can open and run Jupyter notebooks. It is making some good progress these days and seem to be better suited to some people.

[tillahoffmann]

We have started using the JUPYTER_TOKEN environment variable introduced in #2921. It can easily be set using whatever configuration tools you are using (.env files, puppet, etc.).

@Carreau, @takluyver, thank you for all the hard work!

[Carreau]

@Carreau, @takluyver, thank you for all the hard work!

Thanks !

We have started using the JUPYTER_TOKEN environment variable introduced in #2921. It can easily be set using whatever configuration tools you are using (.env files, puppet, etc.).

Oh, I had missed that one. Good point.

[deadhandsignal]

Yes this is the a fckn ridiculous setup when starting to use any application. I'm in a class full of people with the exact same problem, everyone frustrated, need to do better and stop making excuses.

[takluyver]

I've locked this conversation now, because it's generating angry responses, not useful input.

We understand that the security token makes using the notebook less convenient in some situations. As described above, we've done a variety of things to try to mitigate this. We're happy to have constructive discussions about what more we might be able to do. But we're not here to be yelled at when you don't like something.

The DNS rebinding attack is not easy to understand, but it is real, and in the context of Jupyter it could mean that a random website you visit while Jupyter is running could take over your computer. We're obviously not about to take chances with that, so the token mechanism is staying unless someone can find a way to make it clearly unnecessary.