ssh2

Coding agents spend a lot of time in the shell. When exploring a codebase, they usually reach for the same handful of tools: grep, find, ls, cat. We built a public SSH server that hosts Supabase docs as markdown files so that agents can explore them the same way they explore code: ssh supabase.sh grep -rl 'RLS' docs ssh supabase.sh cat docs/guides/database/postgres/row-level-security.md | head -10 Under the hood commands run inside Vercel's just-bash [1] library - an emulated bash shell sandboxed within the JS runtime. It uses a VFS where the docs are mounted as markdown files. SSH is handled by ssh2 [2]. Next step is evals to confirm whether or not this truly performs better than other knowledge retrieval methods (like skills, web search, MCP tools), but we were too excited not to share something now. [1] https://github.com/vercel-labs/j

Neat. I was always wary about unintended side-effects of doing something like this in the main openssh server instance because I did not trust myself to configure everything securely enough without accidentally exposing more than I wanted. While more work than the solution in the blog post, what worked well for me was using [0] to implement a separate server that only exposes whatever you explicitly want it to. It turned out to be pretty feature complete for my use cases (including certificate logins, SFTP, exec and working fine with curses-like applications). [0] https://github.com/mscdex/ssh2

> Shellvault uses a websocket to connect a client-side terminal emulator to an SSH process on Shellvault's servers. When you type a command, it goes through the websocket to the SSH client running on our servers, and the socket sends the response back to the terminal in your browser. So this gives Shellvault complete shell access to your server. It could be improved by terminating SSH at the browser, and just using the Shellvault server as a dumb proxy. Step 1: javascript ssh client - https://github.com/mscdex/ssh2 Step 2: websocket tcp proxy - https://github.com/novnc/websockify Step 3: javascript terminal emulator - https://github.com/rohanchandra/javascript-terminal Step 4: ??? Step 5: Profit EDIT: And a really roundabout way to do this is to run the dropbear ssh client inside Fabrice Bellard's in-browser Linux VM: https://bellard.org/

Great job ! I could not resist to think & share https://github.com/mscdex/ssh2 < SSH2 client/server implementation in nodejs (natural async flow) > piece of art

OSX user; registered as myself. First impressions are not good. • scp very slow; doesn't work • vim scp:// doesn't work • emacs tramp[1] definitely doesn't work (scpx says invalid command; ssh, scp and sftp methods say "EDITOR SOON") I noticed you're using ssh2js[2], but not using its built-in features for getting the public key from the client. I think this would make a much better experience than asking for a password (that you don't echo, don't confirm, and annoyingly don't reset the terminal state afterwards). I also think you should look at getting the sftp subsystem working as it is simpler and much more reliable than scp. I hope you fix these things because I'd like to try it again. [1]: http://www.emacswiki.org/emacs/TrampMode [2]: https://github.com/mscdex/ssh2

I generally use a node script (sometimes a CLI script like [1]) with the ssh2 module [2] for most deployment tasks. [1] https://gist.github.com/4281277 [2] https://github.com/mscdex/ssh2

There's several things left to do: https://github.com/mscdex/ssh2/blob/master/TODO But I wouldn't be so negative, there's plenty of reasons why this might be great / a good idea. (And a lot for it to be a bad one, crypto, security, etc.)