I have come to like SSHFS quite a bit. It lets me use my favourite tools (mainly my $EDITOR and my $SHELL) on remote servers, without having to install them anywhere other than my local machine, keeping things nice and simple. However, the workflow starts to get quite clunky when I need to execute commands on the actual server. I often have to log into a separate SSH session, navigate to the directory I was working in, and execute commands from there, without the niceties of my $SHELL.
That’s where my new tool ssx comes in. I prepend it to a command, not unlike sudo, which lets me run it remotely. It detects that I am in an SSHFS mount and automatically determines where to connect and execute. It has been serving me nicely at work for the past few weeks.
By the way, it comes with a man page, generated using Drew DeVault’s scdoc. I made a super thin Zig package for it if anyone is interested: https://codeberg.org/spiffyk/scdoc.zig
It uses the upstream C sources to compile, but it can also use a system-installed scdoc command, which should make it viable for use in projects that aim to be friendly to distro packagers. (EDIT: I use this capability myself in the provided Nix flake)
oh my god you are a life saver, you don’t even know I’ve been wanting to implement something exactly like that and didn’t find the time to do it. My first attempt got shot mid flight when I naively attempted to basically re implement ssh and got humbled that it’s not simple.
Oh yeah there’s no way I’m reimplementing SSH and trusting that reimplementation… no, this just calls the system ssh command, through that it runs the remote env command, which it then uses to run whatever you typed. It’s kind of a hack, really, but it works pretty nicely.
About the most interesting thing about ssx is probably that it uses the statmount syscall (or, if the syscall is unavailable, /proc/self/mountinfo) to get the information it needs to connect. It’s a dumb little utility, really.
(Though I haven’t yet figured out where to get the SSH port from. Not that I have any servers that use anything other than 22, but it’d be nice to be able to support that as well.)
yeah that was also my conclusion, It was more complex and convoluted that i had anticipated. But in any case I’m so glad that there was a solution and that I’m not forced to have to do sshfs + ssh in 2 terminals. Thank you so much, will report if I find any bug, and neat trick didn’t know about statmount.
Yeah… weirdos like me never run my ssh servers on port 22. (Rather, I always run on a seemingly-random port number, and close 22 entirely; DOS attempts hack all they want in futility.) Anyway, it does mean that I always have to use ssh and scp with -p.
I have been running the tarpit endlessh on public facing servers on port 22. I put the alternative port for these servers in the ~/.ssh/config of the devices (my laptops and server at thome) accessing that server:
Host xyzN
Port 1234
User ernie
HostName 12.34.56.78
ForwardX11 no
(with xyz a client identifiying short name and N the number of the server). That way you don’t have to remember the port number for each server.
When you update the port number for a server, after it has been scanned and is being probed, make sure you can access the new port and then, update the config file. Optionally run endlessh on the previous alternative number.
