On Mar 2, 2008, at 6:29 AM, Andy Armstrong wrote:

On 2 Mar 2008, at 13:46, Joshua Juran wrote:
I tried setting up a local HTTP server with a CGI script that invokes my preferred editor, forwarded the port over ssh, and then using an 'editor' that sends the file over HTTP and receives it back. It basically works, except that ssh port forwarding sucks because it wants me to pick the port number. I don't give a rat's ass which port it uses, but it thoughtfully makes me pick one so that it's my fault when it conflicts with either one chosen by hypothetical other users on the remote system, or very real other local systems I'm connecting from. If ssh could just pick a free port and then set an environment variable saying which one it was, that would be very cool, except of course for allowing ANYONE ON THE REMOTE SYSTEM to connect to my forwarded port. WTF!? How about forwarding to a unix-domain socket? Am I really the first person to think of this?


Doesn't a little script that does rsync, edit, rsync cut it?

Assuming you mean from the local system: No. That fails to reuse not only the context implicit in the remote shell (foreign host, current directory), but also the perfectly good already-established ssh tunnel. If I don't have authorized keys set up I'll even have to enter my password again.

Josh


Reply via email to