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
The video that shows this is exactly how this should work. Using the device flow is a much nicer solution because the user does not have to copy/paste any codes in the terminal.
The sessions can run with the ssh daemon being accessible only from the ssh proxy (this can be enforced via a network policy in k8s). The ssh proxy will authenticate the user and check if the session the user is trying to access truly belongs to the user. If the user owns the session then they can access it, if not they will not get ssh access.
And the username in the ssh command can be the session name. So if your session name is tasko-2eol-test-2d24-978c86c4 then the ssh command people run would be ssh [email protected] -p 2022. I think that port 22 is taken for ssh access to gitlab so we would have to use 2022 but if port 22 is available then the command would be even simpler.
The proxy does not even need to save any of the access or refresh tokens from the flow. If the oauth2 flow is successful it means the user is who they say they are. If they want to open another ssh session the flow is repeated. I think repeated ssh attempts will not ask for credentials since they will be saved in a cookie in the browser. They will just have to open the browser and click "Log In" or "Accept" and close it.
The text was updated successfully, but these errors were encountered:
See: https://containerssh.io/v0.4/blog/2021/04/13/devlog-oauth2/
The video that shows this is exactly how this should work. Using the device flow is a much nicer solution because the user does not have to copy/paste any codes in the terminal.
The sessions can run with the ssh daemon being accessible only from the ssh proxy (this can be enforced via a network policy in k8s). The ssh proxy will authenticate the user and check if the session the user is trying to access truly belongs to the user. If the user owns the session then they can access it, if not they will not get ssh access.
And the username in the ssh command can be the session name. So if your session name is
tasko-2eol-test-2d24-978c86c4
then the ssh command people run would bessh [email protected] -p 2022
. I think that port 22 is taken for ssh access to gitlab so we would have to use 2022 but if port 22 is available then the command would be even simpler.This video shows the flow: https://youtu.be/SGHee9cV_rA
The proxy does not even need to save any of the access or refresh tokens from the flow. If the oauth2 flow is successful it means the user is who they say they are. If they want to open another ssh session the flow is repeated. I think repeated ssh attempts will not ask for credentials since they will be saved in a cookie in the browser. They will just have to open the browser and click "Log In" or "Accept" and close it.
The text was updated successfully, but these errors were encountered: