Open williamstein opened 1 year ago
Also, It's annoying that you get halfway through configuring your sshfs mount, go to make or find an ssh key, and when you come back your configuration is gone...
Also, an obvious additional thing to check for when choosing a private key would be to use the one for the very project you're configuring. Often projects have an ssh private key, if the user recently attempted, and failed to use sshfs in the terminal.
Also, the sshfs error message is NOT helpful at all in the terminal. It should say how to solve this problem:
If you have an sshfs mount, and the remote machine goes down, then the entire project just hangs with "Connecting...". It's basically completely broken, but there's no indication anywhere as to why.
Fortunately, restarting the project does fix the problem (and doesn't break our Kubernetes servers, fortunately).
When the project comes back the broken sshfs mount does this:
~$ ls /data
ls: cannot access '/data/compute': Transport endpoint is not connected
compute compute_output.md
~$
I'm just pointing out some concerns about the user experience with remote filesystems, in the hopes of someday revisiting this and improving things.
Instead of requiring the user to create their own private key, just have an option to autogenerate one. That private key never needs to be revealed to the user at all, which would make this functionality (1) much more secure, and (2) much easier to use.
So the private key would be generated and stored in our database. The user would see a public key, and would be asked to add it to their remote server so they can connect.
I'm not saying this should be the only option. Just that it would be a good additional option.