I don't think so. As much as I like oh-my-zsh, I wouldn't want its massive code base and attack surface to be forwarded to sensitive or critical servers.
Shells require integration with the rest of the system, which involves automatically executing certain scripts based on program availability for autocomplete. That's difficult to do when you don't know what kind of system you're remoting into. You can't reuse the same configuration for remoting into an old Ubuntu 12.04 machine and for remoting into a Windows 11 powershell prompt without losing most functionality you want out of a more-than-basic shell.
If you want a unified shell, you'd probably want to set up a layer between the user interface and SSH (on both sides) to make this possible.
> I wouldn't want [oh-my-zsh's] massive code base and attack surface to be forwarded to sensitive or critical servers.
I think we agree here. I said "The shell should [not be] a program running on the remote system."
> You can't reuse the same configuration for remoting into an old Ubuntu 12.04 machine and for remoting into a Windows 11 powershell prompt without losing most functionality you want out of a more-than-basic shell.
Why not? Why couldn't a single shell program understand PowerShell objects, Windows and Linux environment variables, and Bash/Fish/Zsh completion scripts?
I suppose it could, but you'd be building several shell languages into a single program to support it, including support for the necessary aliasing and macros that system shells (ab)use for system configuration.
I think the system you propose would require a fat server to properly serialize the necessary contents back to the user's shell. In effect you'd be writing a replacement for an ssh server with deep integration into whatever shell the user is running locally. The alternative, constantly dumping the shell state and interpreting it, would be easy to get wrong, and desyncs of local and remote state could have a severe impact on the commands you run.
It's not technically impossible, just very impractical. I think it also goes against the philosophy of "do one thing and do it right" because of all the moving parts.
I think what the commenter is saying is that you shouldn’t “remote in” to a shell; you should use your regular old shell and have it send commands to a server and display whatever it receives back to you. The shell should be an abstraction over a computer; it shouldn’t be integrally tied to any particular computer as they are today
But you can't move the shell across layers. It's needed where it is.
The point of the shell is that it's how you issue commands to the computer. You (or GP) want to make the commands independent of the shell. OK. How do you issue your new shell-agnostic commands? How is the computer supposed to understand them?
For that to happen, you'll need to implement a shell in the exact place where you just removed the first one.
The app captures syscalls working on FDs and forwards those to the remote side. You could do that in much more clever ways. You can also do it in hacky simple ways like for example ansible does, by just running each command remotely.
OK, so on the server we have a protoshell running which accepts commands and makes system calls.
(I don't think your three-part listing makes sense: commands are the input to the shell, and system calls are the output. But you can't separate them -- without input, what output are you producing?)
And now, on the client, we have a command editor running which accepts keystrokes and produces commands.
But the client runs on a different machine. It doesn't know what commands the protoshell over on the server can accept. How does it know what commands to produce?
... while sacrificing features like auto-complete, shell awareness (Git branch and other doodads people love to put in their prompt), and persistence (screen/tmux/mosh).
Why ? You have the browser for such things. In UNIX a shell is a shell, a console is a TTY (that's where the output of a shell mostly goes) and a terminal emulator is a TTY emulator.
I think the use case of a browser and a shell is quite different. I don't know what a browser would look like if it had an easily-scrollable log like a terminal does.
I think you have a good point about a browser being a GUI version of the shell. I'm not proposing a GUI shell, though, but a shell which lets me run TUI/console programs.
hardly more complex. imagine if the operating state was expressed in some common data format - just imagine tables. and the shell then is my local preference that interacts with that data model.
is that less or more complicated than the mishmash of oddly designed kernel interfaces we have today (fork. mmap. ptrace....so much of it is a mess)
not only would that clean up the lot, and allow for a very straightforward remote indirection, but would open up all kinds of lovely usages like being able to trivially capture and replay command streams. interposition. general purpose rewrites. a well-defined domain in which to upgrade and downgrade the interface schema. and more things I'm sure I've never thought of.
And imagine that you have a bug. And that you trash the filesystem remotely but by you it looks ok.
Nobody asks you to use a shell with ssh. You can use X or (when or if will ever suport such an outdated feature) wayland.
Portability of shells/binary injection and the associated layers often come with extreme vulnerabilities that are often not officially discovered for years. Convenience is often the reason many new vulnerabilities are introduced. Cool project for hobby purposes but be cautious when using this sort of thing on production systems especially on those housing data of any importance.
If they don't want you to fling binaries into your home directory they should just mount it noexec. At any rate it doesn't seem like a fantastic security/ability-to-work trade-off. Limit the privileges of the account or you're one exploit away from trouble.
Many redundant layers are used to prevent and/or detect security violations, but “don’t install random binaries on prod machines” is a basic tenet. If you need certain tools to do your job, deploy them via proper controlled and audited mechanisms, not via scp.
Nice, I did a similar hack some time ago: pack your favorites functions/aliases in b64, unpack and do some mkfifo on the server, write that fifo path to ENV, and call "exec bash --posix". zsh and ksh also work, as they also have some options relying on ENV.
It doesn't seem to work as I expected - I run xxh user@myhost +s zsh. I just get a blank zsh prompt without any of my dotfiles or anything. Is it supposed to be configured somehow beyond this?
At my company we sometimes have to SSH into our dev nodes to restart things, figure out what's going wrong, etc. But we wipe them out nightly to update the code.
This tool would let you keep all your special aliases for working on the nodes without manually copying your config(s) over.
Can't say I'd use it, but I can see use cases like the above.
Why not just have the instance run a script to fetch a new .rc file from a local repo? Or better yet just include the aliases in the profile/rc file on the image itself.
The instance would need to have extra credentials for that I suppose, and you'd need the repo up somewhere, then track everything with git.
Lots of engineers are also using the nodes, so you'd need to share that repo with them then have some command you type in each time to load it after you ssh into the node.
And you'd only have updated versions of your rc every night, unless you want to commit a change, push, go to the server to pull it down, reload the shell.
I guess what I'm saying is this tool fills a niche and avoids all the above complexity just for some shell aliases.
(btw I don't really have a use for it, I just have 2 or 3 commands to copy paste into the shell for 99% of what I need to do. Just maintaining the argument to hear alternatives from people!)
As long as the commands are not secret, you could have your terminal just fetch them from a web server after logging in via the console and source it if the hash checksum of the page equals an expected value. If the checksum does not meet the expectation you either updated the commands in the file without updating the expected hash or the file server has been compromised.
It's a program whose only purpose is to download/build some executable files, transfer them to a remote host, and then execute them. That would seem to encompass both "distributing" and "running" software.
The shell should be part of the user interface (e.g. the terminal emulator or console), not a program running on the remote system.