Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feat]: Add jupyter-style runtime generated token #5819

Closed
mlzxy opened this issue Nov 26, 2022 · 3 comments
Closed

[Feat]: Add jupyter-style runtime generated token #5819

mlzxy opened this issue Nov 26, 2022 · 3 comments
Labels
enhancement Some improvement that isn't a feature

Comments

@mlzxy
Copy link

mlzxy commented Nov 26, 2022

What is your suggestion?

  1. I propose to remove the --auth none option, which means all code-server instances will run with password/token protection
  2. Add jupyter-style runtime generated token as the default or additional authentication option, for example, the following log are printed from jupyter lab:
    0|jupyter  |     To access the server, open this file in a browser:
    0|jupyter  |         file:///path/to/a/local/file.html
    0|jupyter  |     Or copy and paste one of these URLs:
    0|jupyter  |         http://ip_address:8888/lab?token=4b0b5b4e9f0b113082e9410f71048994139195036bc224e2
    0|jupyter  |      or http://127.0.0.1:8888/lab?token=4b0b5b4e9f0b113082e9410f71048994139195036bc224e2 
    

Why do you want this feature?

Many people, including myself, enjoy the convenience of --auth none. But this create a serious potential security threat for the underlying system, considering code-server provides bash interface through web.

I personally experienced a hijack that turned one of my working GPU cluster machines into a crypto miner. The unattended code server turns out to be their starting point. It is difficult to diagnose since they won't even leave ssh login history, and I am surely not the only victim.

I agree that the --auth none enables a convenient option for people to try code-server quickly, but I would argue the same level of convenience could be achieved with the jupyter tokenized URL option, as in the example above.

Are there any workarounds to get this functionality today?

I would imagine a system administrator could preinstall code-server and wrap it in order to provide an auth-only interface to users.

Are you interested in submitting a PR for this?

Sadly I am not a web developer, but I would see what I can do if this feature request becomes well accepted.

@mlzxy mlzxy added the enhancement Some improvement that isn't a feature label Nov 26, 2022
@benz0li
Copy link
Contributor

benz0li commented Nov 29, 2022

  1. I propose to remove the --auth none option, which means all code-server instances will run with password/token protection

code-server is password protected by default. One has to explicitly set --auth none to remove it.

I am running code server with --auth none in a JupyterLab image behind JupyterHub.

I don't see why the --auth none option should be removed.

@shawnweeks
Copy link
Contributor

There also those of us using reverse proxies and other kinds of secure external authentication for code-server. Forcing a token would greatly limit deployment options.

@code-asher code-asher changed the title [Feat]: Remove --auth none option and add jupyter-style runtime generated token [Feat]: Add jupyter-style runtime generated token Jul 12, 2024
@code-asher
Copy link
Member

Closing in favor of #3546

@code-asher code-asher closed this as not planned Won't fix, can't repro, duplicate, stale Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Some improvement that isn't a feature
Projects
None yet
Development

No branches or pull requests

4 participants