[montroser]

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

[Y_Y]

There's definitely something be said for speaking the common tongue, and being able to use the defaults when it's necessary. I have some nice customisations, but make a point of not becoming depwndent on them because I'm so often not in my own environment.

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.

[cyanf]

Why would you want to ssh into a machine that's not yours? That's a violation of the Computer Frauds and Abuse Act, up to 10 years in prison!

[montroser]

I think you're joking, but to clarify -- not personally yours. A misbehaving worker box, an app server in the staging environment, etc. A resource owned by the organization for which you work, where it would not be appropriate for you to customize it to your own liking

[otterley]

When you have permission to do so, it isn’t.