Closed geoHeil closed 3 years ago
When subsequently stopping & restarting (= probably getting a runtime on a different collab host:
ssh tension-interracial-it-delivered.trycloudflare.com
The authenticity of host 'tension-interracial-it-delivered.trycloudflare.com (<no hostip for proxy command>)' can't be established.
ECDSA key fingerprint is SHA256:4EsnMyolP9JhGnuK9B8ppHo8C53mNKsNst81ip/sdaM.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'tension-interracial-it-delivered.trycloudflare.com' (ECDSA) to the list of known hosts.
root@tension-interracial-it-delivered.trycloudflare.com's password:
when entering the password an SSH connection seems to be established. I will try to test it in some minutes
But it is unstable. (at least for me). Oftentimes I still get the WebSocket error message.
But if the connection works, port forwarding works reliably. This is good.
Do you have any suggestion why it seems to only work on every second start of a collab VM for me?
Hello @geoHeil, Welcome to colab-ssh community. Thank you for submitting this issue.
If I understand correctly, the connection only gets established after the first try (which fails). Correct ?
EDIT I just tried to reproduce the issue, I tried running the script you suggested in the reproduction steps. But unfortunately I didn't have any WebSocket error. This could be an issue with cloudflared. They sometimes face temporary degradation.
If this issue persist feel free to post other reproducible steps or a video showing the steps you mentioned. If you face this issue again, you can always try to check out colab-ssh ngrok documentation which is a good alternative to cloudflared.
Cool thanks! But didn`t you switch to cloudflared due to some hiccups in Collab? I was using the old method and was redirected / strongly suggested to use this new method.
I think having this partially working state is good enough for me for now.
Cool thanks! But didn`t you switch to cloudflared due to some hiccups in Collab? I was using the old method and was redirected / strongly suggested to use this new method.
I think having this partially working state is good enough for me for now.
At colab-ssh we highly care about the stability of the library, the ngrok method has stopped working for unclear reasons frustrating all developers using colab-ssh, even though it's working again now, it's important that we ensure that the interruption won't happen again or at least very unlikely to happen again. Therefore, we are closely monitoring the stability of both cloudflared and ngrok, and for now cloudflared is more reassuring than ngrok.
A possible solution for this, is probably to provide a common API that uses a default tunnel service (either cloudflared or ngrok) based on an option chosen by the colab-ssh team. The only problem with this, is that both services do not have common arguments (For example ngrok requires a token in the parameter after making an ngrok account).
I am going to close this for the time being, if anyone faces a similar issue feel free to comment or create a new issue.
Describe the bug the connection does not wor (and fail for me) on osx with:
after setting up the SSH config file as suggested in the client machine configuration by launch_ssh_cloudflared
To Reproduce Steps to reproduce the behavior:
!pip install colab_ssh --upgrade
2.1 imports:from colab_ssh import launch_ssh_cloudflared
Expected behavior a working SSH connection