Replies: 9 comments 9 replies
-
We are calling out to the package without any arguments so it uses whatever defaults they have configured. They say the defaults are "according to the security recommendations by the team that develops Argon2" and you can see them here: https://github.com/ranisalt/node-argon2/wiki/Options.
It might be a good idea to add a way to have code-server take your password and spit out the hash (similar to I wonder though if you really need to use the hashed password and could use a plain text one instead? If an attacker gains access to the password file, they already have access to the container, and if the passwords are unique they have no further utility. There could be an angle I am not seeing though.
No, the rate limiting is purely in memory. |
Beta Was this translation helpful? Give feedback.
-
|
Also, it might be better to have an authenticating system outside of code-server, and forgo code-server's cookie altogether. Sounds like you might already have the infrastructure to make that happen, but maybe there are complications that are forcing you to do this hybrid auth setup. |
Beta Was this translation helpful? Give feedback.
-
|
Replacing the "/login" sub-path of code server, and using our authentaction system, and setting the session-cookie, just seemed There will be a LOT (500+) users, though we expect only a maximum of around 60 at any one time. Previously we were creating the container and assigning a random password that we give to the authenticated user, for them to copy-n-paste so as to login to code-server. It needed a redis database to hold information about the user, even though once the user was logged into code-server they no longer needed to use the authentation system. That system has been in use for more than 5 years, in a docker environment. Now we are migrating to a kuberneties system, and want to simply pick up the already generated password (from the code-server config file) set the session cookie, and direct them to code-server. No more copy-n-pasting. They just go to their development environment, Users never actually need to know their code-server password! They just login to our systems as normal (if not already), and they have access to their code-server (and no one elses). Most of the time code-server accepts the hash we create from the password. I have confirmed the session-cookie hash I generate verifies against the password stored in the code-server. But when code-server doesn't accept the session cookie as valid, it jumps back to the '/login' sub-path, their auth is transparently and quickly confirmed, and a new hash of their password is set as the cookie, before it again ends them back to code-server top-level. What is happening is that when the cookie is not accepted. No re-hashing of the password gathered from the code-server config, ever seemed to be accepted as valid! This results in a endless browser re-direction loop (until browser put a halt to it). At first I thought the cookie was being reset and lost. But it is still present when the users browser is redirected back to our auth system, and I have again manually confirmed that the refected cookie hash, does verifiy against the config password. Then I thought it was the argon2 params being checked, and found to not be good enough as I had been forced to use less secure parameters (thus the original request). That has now been resolved. Example params Now I got the feeling that the code-server is internally using a slightly different password to what it had written in its config file. Basically the hashed password I set the cookie to, is either accepted first time, It never accepted at all, And yes The system would be a LOT simpler if the session cookie was simply the code-server generated password |
Beta Was this translation helpful? Give feedback.
-
|
Okay... Found the faults. I had HttpOnly set on the cookie. I don't know why it was sometimes working, while other times it didn't. On monday I will post here some of the password/cookie testing 'curl' commands I used to debug this, but right now -- weekend! Yeah! |
Beta Was this translation helpful? Give feedback.
-
|
This is driving me batty! I call my replacement login which sets a cookie... |
Beta Was this translation helpful? Give feedback.
-
|
Huh...that is strange. Thinking out loud...
I think 2 is the setup you have. So either the cookie is somehow unset during the redirect or I experimented but I have not been able to reproduce unfortunately. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the information about Extra logging under would be useful. I was using "--log debug" (from years ago) but I suddenly realised it is not listed in "--help" output. Switching to "--verbose". Having it log if it hits the 2 per minute or 12 per hour limit would be good too. Having some way of turning that OFF for debugging would be good too. I gather that limit is reset if code-server restarted. That may be causing half my frustration during testing. |
Beta Was this translation helpful? Give feedback.
-
|
Yup from my testing it is after decoding. And yup the limit is in memory so it resets if code-server restarts. I opened #7396. |
Beta Was this translation helpful? Give feedback.
-
|
Okay I have it working! /login is overlaid with our own authentication system, by our kuberneties ingress system. When user and domain is validated the completely random (long hex key) One point. if a Even though there is no password set in that file (just the hashed-password) all else is set via command line. Thank you for your help... |
Beta Was this translation helpful? Give feedback.
-
|
Glad to hear it!!
Oops, I will fix that right now. Thanks for spotting it! |
Beta Was this translation helpful? Give feedback.
-
|
Oh hum.... First I added some temporary debug loging to isCookieValid() in node/util.js case "SHA256":
isValid = (0, safe_compare_1.default)(cookieKey, hashedPasswordFromArgs);
logger_1.logger.debug(`isCookieValid: '${isValid}' = '${cookieKey}' '${hashedPasswordFromArgs}'`);That way I can see if it is 1 getting the cookie, see what the cookie is, and that it is validating correctly! So when I jump first jump into code-server (an old cookie set) I see in the logs... Then the failure due to the cookie being wrong (or empty if not set). All good. My /login replacement authenticates the user, and sets the right cookie. and so on... ALL WORKING PERFECTLY... (PS I am GMT+10) Later after some time... (went to morning tea) I com back and as soon as I start working... But in code-server logs... The first line was last interaction before morning tea... From this point on... When ever I go back to the top level '/' It always redirects back to /login Strange When I jump to "/?folder=/var/www" It worked! Again! BUT later (when window 'disconnected, and needed to reconnect... Actually it does not appear to be even trying to test the cookie in this 'permanent' failed state. If I don't hear from you by monday, I'll start adding loggin on EVERY redirect I can find to try and backtrack the cause. |
Beta Was this translation helpful? Give feedback.
-
|
Oh! Huh. I have no idea how that happens. It feels like something low level. I am not sure if it is related to the redirect issue, but it seems possible. Could even be a Node bug maybe?? |
Beta Was this translation helpful? Give feedback.
-
|
So what would you like me to do to help you? Last time we stopped idle code-server virtual machines, after a couple of hours inactivity according to the heart beat file. (Just an open terminal was not enough to keep heart beat working, which is why it is 2 hours). Users would then restart them, and could re-start them any time they like. (Running on Docker) This time though we are planing to keep all the users code-server virtual machines running indefinably, as it would mean the authentication system does not need any access to control the virtual environment. The users code-server is already running. Basically as this is a lot more difficult to do under kuberneties. Note that once it gets into this state, restarting code-server does NOT fix the problem, even in a reset browser. Perhaps code-server /login does something to reset the '0 active connections' condition, which of course I would not be doing? |
Beta Was this translation helpful? Give feedback.
-
|
Actually, that makes me realize the limiter should be having any effect on what you are doing because we are not rate limiting authentication attempts using a cookie (although we should be), at the moment it is only on POST requests to I wonder if there is some kind of resource starvation going on? Is it running out of memory or file descriptors or something? Not sure why it would not error if that was the case though. 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
I figured out from code exploration that the limiter was only in /login. So not an issue. Okay it is happening. pod is now using 150Mi memory, but its limit is currently 2Gi so no resource limitations. Note the File not found in this log! If it helps. Hmm... There is a 'node' process that is defunct! Could that be the cause? Looks like process 126 has been inherted by process 1, which means its original parent had died, before it exited, Hmm... suddenly It is working again! Arrggghhh.... |
Beta Was this translation helpful? Give feedback.
-
|
Back tracking to my proof of concept version. (very small). This uses a plain code-server container... Then has the kubernetes ingress overlay the '/login' with a VERY small bash-socat webserver to just set the cookie, on ANY request under the './login' path. It works perfectly fine. Even after running all day! If I try to 'logout' of code-server, it jumps to '/login' cookie gets set again Of course this has a fixed argon2 hashed password, which code-server accepted just fine. It has none of the Authentication, find users home, retrieve the code-server password (or hashed-password), set a cookie, Tomorrow I am stripping down my user development environment, with code-server in apache-php image to try and ensure it working in the same setup. |
Beta Was this translation helpful? Give feedback.
-
|
Well you were right... it all came down to resource limits. Arrrgghhhh... For a period I even thought perhaps it was nodejs interactions, as we also install a v18 of Node, while code-server is using Node v22 Thank you greatly for your help, especially with regards to the session-cookie. We no longer use a argon2 hash for this, just set a random string as the "hashed-password" in the code-server config.yaml file, every time code-server is restarted. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome glad to hear it!! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In a kuberneties environment where I will be running multiple code-server containers (one per user)
I have created a ingress 'overlay' for the code-server "/login" which (after confirming the users identification against our OAuth2 server) grabs the password for the user's code-server, hashing it, and sets it has the users code-server-session cookie, before returning the to code-server proper. This IS working and means we can set ANY authentication system we like (SSO in our case, so users often are already authenticated!)
This has works very well, though I find that code-server has some very specific 'requirements' for the argon2 has it requires.
Too low a iteration, parallelism, or memory and it just rejects it provided hash cookie, redirecting back to the "/login" web overlay, so as to try again. (and getting into a redirect loop, until browser breaks it!)
Unfortunate the "Go" language argon hash is woefully bad, in that it has no clean error handling and just CRASHES the program if it can't get the resources to hash the users password! This sets upper bounds on the argon2 hashing parameters we can use.
THE QUESTION: What exactly is the requirements code-server has for an acceptable argon2 hash?
Alternative (and this is not as good, as the hash become static until environment is restarted)
Is their a way to get code-server to provide an acceptable hash instead of having the hash or some other session cookie?
is the password repeat failure limits saved to disk? If so where?
Beta Was this translation helpful? Give feedback.
All reactions