Supported: .profile, .vimrc, .bashrc, .tmux.conf, etc.
This idea comes from kyrat[1]; passing files via a base64 string is a really cool approach.
scp my-precious-dotfiles remote:~
trap 'ssh remote rm my-precious-dotfiles' EXIT
ssh remote
I'd hate to jump to conclusions, but what username are you looking into what machines with for that to be an issue?
Wouldn't it make more sense to have a tool that brings files over to the local computer, starts Vim on them, and then copies them back?
It has an activate script which sets PATH, XDG_CONFIG_HOME, XDG_DATA_HOME, and friends. This way everything runs out of that single dir and doesn’t pollute the remote.
My ssh RemoteCommand then just checks for and calls the activate script if it exists. I get dropped into a nice shell with all my config and tools wherever I go, without disturbing others’ configs or system packages.
One of the engineers wrote a shell alias called “shitssh”, which would call ssh with the right options to allow the old crufty crypto algorithms to be used. This alias got passed down to new members of the team like a family heirloom.
I hate network vendors. Wish I could put BSD on my old Catalysts.
tmp="$(mktemp -d)" && rsync -a --exclude='.ssh' user@host:~/.[!.]* "$tmp"/ && HOME="$tmp" exec "$SHELL"It's surprising to me how many projects can be replaced with just a line or two of shell script. This project is a slightly more sophisticated shell script that exposes a friendlier UI, but I don't see why it's needed when the alternative is much simpler, considering the target audience.
git clone $uri dotfiles; export HOME=$(pwd)/dotfiles
Rant (not directed at any comment here): If it's a production server without git, then please do not run scripts like this. Do not create junk directories on (or ideally any modifications to) secure machines. It inevitably causes new and uninteresting puzzles for your colleagues. Create documented workflows for incident responses or inspection.
On the other hand, if the remote machine is mine, it will have my config anyway.
$ tar cf - ~/.shrc | ssh target '(cd ~ && tar xf -)'That said, for personal servers this is brilliant. I've been using a git repo for dotfiles but having them automatically cleanup on disconnect is clever.
One improvement: consider using SSH's ProxyCommand or LocalCommand instead of wrapping SSH entirely. That way it works transparently with tools that call SSH directly (git, rsync, etc).
Also curious - does this handle tmux sessions properly? I often SSH in, start tmux, disconnect, then reconnect later. Would the dotfiles still be there?
https://erock-git-dotfiles.pgs.sh/tree/main/item/dotfiles.sh...
This installs into temp dirs and cleans it all up when you disconnect.
Personally, my old-man solution to this problem is different: always roll with defaults even if you don't like them, and don't use aliases. Not for everyone, but I can ssh into any random box and not be flailing about.
Even with OP's neat solution, it's not really going to work when you have to go through a jump box, or have to connect with a serial connection or some enterprise audit loggable ssh wrapper, etc
On the other hand, your comment has me wondering if ssh-agent could be abused to drag your config along between jump hosts and enterprise nonsense, like ti does forwarding of keys.
On that note, I didn't see any mention of https://github.com/romkatv/zsh4humans/blob/master/tips.md#ex... , so there.
${HOME} is where your dotfiles are.
e.g. I type an alias, the ssh client expands it on my local machine and send complex commands to remote. Could this be possible?
I suppose a special shell could make it work.
Because the processes that use them run on the remote machines.
> I type an alias, the ssh client expands it on my local machine and send complex commands to remote.
This is not how SSH works. It merely takes your keystrokes and sends them to the remote machine, where bash/whatever reads and processes them.
Of course, you can have it work the way you imagine, it's just that it'd require a very special shell on your local machine, and a whole RAT client on the remote machine, which your special shell should be intimately aware about. E.g. TAB-completion of files would involve asking the remote machine to send the dir contents to your shell, and if your alias includes a process substitution... where should that process run?
Yes but but does the process have to read from a file system dotfile, instead of some data fetched over a ssh connection?
> your alias includes a process substitution
Very valid point. How about a special shell only provides sys calls and process substitution on remote, the rest runs on local client, and communicate via ssh?
I understand this will make client "fat" but it's way more portable.
Working on it! :)
Remote machines usually don’t need to know your keystrokes or handle your line editing, either. There’s a lot of latency to cut out, local customization to preserve, and protocol simplification to be had.
It’s not bad software, it’s also not mature. I’m currently on a phone and on vacation so this is the extent of my review. Maybe I’ll circle back around with some PRs next week