Description
What is your suggestion?
- I propose to remove the
--auth none
option, which means all code-server instances will run with password/token protection - 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.