You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
What is your suggestion?
--auth none
option, which means all code-server instances will run with password/token protectionWhy 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.
The text was updated successfully, but these errors were encountered: