I often need to login to colleagues' machines at work, but I find that their settings are not what I am familiar with.
So I wrote an SSH wrapper in POSIX shell which tars dotfiles into a base64 string, passes it to SSH, and decodes / setups on the remote temp directory. Automatically remove when session ends.
Supported: .profile, .vimrc, .bashrc, .tmux.conf, etc.
This idea comes from kyrat[1]; passing files via a base64 string is a really cool approach.
I came across something similar a few months ago. I pieced together a working hybrid by patching in parts from an older release with the latest version. I didn't ever work out if the latest version failed because of something in my environment or not, but I'm on a Mac fwiw.
I have a python script [0] which builds and statically links my toolbox (fish, neovim, tmux, rg/fd/sd, etc.) into a self contained —-prefix which can be rsynced to any machine.
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.
This reminds me - in a previous company I worked at, we had a bunch of old firewalls and switches that ran SSH servers without support for modern key exchange algorithms etc
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.
Nice, although wouldn't work today. Modern distros (ime, fedora 42) need you to update policy and reboot. You can't connect with just --key-exchange YOLO1 any more
I hate network vendors. Wish I could put BSD on my old Catalysts.
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.
These days, my laptop acts as a dumb SSH gateway for Linux VMs. No configuration or setup, aside from VS code connecting to VMs. Any server that I would want to load my dotfiles onto will almost always have git installed.
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.
How about mounting your dotfiles directory (~/.config) or even your entire home directory on the remote system using SSHFS or NFS? I'm sure somebody would have tried it or some project may already exist. Any idea why that isn't as prevalent as copying your dotfiles over?
That requires the remote machine to be configured to SSH into your local machine. In the scenario where OP's project is useful (SSH to foreign machines) I might not want that.
On the other hand, if the remote machine is mine, it will have my config anyway.
I didn't look closely at the project, but why take the extra step of base64? I do this all the time with tar by itself and it's wire-proof enough to work fine.
I love the concept but I'd be worried about security in enterprise environments. Some of the dotfiles (especially .bashrc) could override security policies or compliance settings that IT has configured.
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?
People who choose such a noxious name for their project that it actually dissuades people who might otherwise be users think that says something about those prudish users, but it really says something about them.
I have a dotfiles git repo that symlinks my dotfiles. Then I can either pull the repo down on remote machine or rsync. I’m not sure why I would pick this over a git repo with a dotfiles.sh script
This is for when you have to ssh into some machine that's not yours, in order to do debugging or troubleshooting -- and you need your precious dotfiles while you're in there, but it would be not nice to scatter your config and leave it as a surprise for the next person.
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
I have been doing something similar for years, especially for login to VMs: sets up an environment of my dotfiles based on a checkout and runs a resumable 'screen' session with tmux. This looks elegant (ephemeral), but I seldom log in to a machine I can't leave my files on as installed.
> I wonder why are dofiles have to be on remote machines?
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?
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.
I don't know, I just use the standard on my machine or on remote. Why bother to customize it all the time when you can't work without the customizations
Be careful, this will force your defaults over system defaults possibly overriding compliance or security settings. There are a few places I noticed where well-placed malware could hop in etc.
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
sdovan1|2 months ago
Supported: .profile, .vimrc, .bashrc, .tmux.conf, etc.
This idea comes from kyrat[1]; passing files via a base64 string is a really cool approach.
[1]: https://github.com/fsquillace/kyrat/
Joker_vD|2 months ago
alsetmusic|2 months ago
https://github.com/cdown/sshrc
unknown|2 months ago
[deleted]
fragmede|2 months ago
I'd hate to jump to conclusions, but what username are you looking into what machines with for that to be an issue?
amelius|2 months ago
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?
xuhu|2 months ago
foltik|2 months ago
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.
[0] https://github.com/foltik/dots
stijnveken|2 months ago
throw2772|2 months ago
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.
psd1|2 months ago
I hate network vendors. Wish I could put BSD on my old Catalysts.
Y_Y|2 months ago
grepfru_it|2 months ago
imiric|2 months ago
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.
flakes|2 months ago
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.
sdovan1|2 months ago
goku12|2 months ago
sigwinch|2 months ago
cl3misch|2 months ago
On the other hand, if the remote machine is mine, it will have my config anyway.
vbernat|2 months ago
drewr|2 months ago
unknown|2 months ago
[deleted]
sigwinch|2 months ago
owl_vision|2 months ago
twp|2 months ago
https://www.chezmoi.io/reference/commands/ssh/
thunderbong|2 months ago
https://github.com/cdown/sshrc
K0IN|2 months ago
https://github.com/xxh/xxh
yoan9224|2 months ago
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?
ghostly_s|2 months ago
allarm|2 months ago
qudat|2 months ago
https://erock-git-dotfiles.pgs.sh/tree/main/item/dotfiles.sh...
montroser|2 months ago
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
5-0|2 months ago
On that note, I didn't see any mention of https://github.com/romkatv/zsh4humans/blob/master/tips.md#ex... , so there.
gbraad|2 months ago
${HOME} is where your dotfiles are.
unknown|2 months ago
[deleted]
est|2 months ago
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.
Joker_vD|2 months ago
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?
minitech|2 months ago
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.
neocron|2 months ago
tensegrist|2 months ago
grepfru_it|2 months ago
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
darrenf|2 months ago
deadbabe|2 months ago
throw20251220|2 months ago
simmo9000|2 months ago
[deleted]
MKWIX8CXX|2 months ago
[deleted]