sshrc – make your ssh sessions feel like home | Hacker News Reader

sshrc – make your ssh sessions feel like home

github.com

235 pointsRussell9144 comments

Ouch, this is a better version of what I submitted a few days ago [1]. I guess that's what I get for trying to emulate the unwieldiness of ssh_config.

[1] https://news.ycombinator.com/item?id=8324538

The title of your post is less catchy and less clear, which for good or for bad likely had an effect on the outcomes of these two submissions (and frankly I bet had much more to do with anything than the actual technical details: frankly, your assh looks much more powerful in valuable ways, and doesn't seem overly complex to use either).

I feel like this should be out of the box ssh functionality. This is exactly what I've needed my whole sshing career.

I made myself a simpler version of this a while back. I would simply put the rcfile in a folder and then host that folder with:

  python2 -m SimpleHTTPServer 12345

Then you can just use something like the following function to get a remote session:

  sshrc() {
    ssh -R 12345:127.0.0.1:12345 -t ${*:1} 'bash -c "bash --rcfile <(curl -s http://127.0.0.1:12345/sshrc)"'
  }

This has some nice side effects in that you can then just host your vimrc the same way. I think you can get vim to load plugins from a http runtime path too, but I have never looked into it.

Doing it this way has its own quirks though.

Something similar, which allows you want to extend shell scripts to a remote system transparently is "rpcsh" -- take a look at: https://gist.github.com/derekp7/9978986

This function allows you to push out local functions, variables, and arrays to a remote system. There is an updated version in the client script for my backup utility (snebu), which also includes getting remote variables returned to the local shell script, and also bouncing through sudo.

Should I move this to a regular project on Github, or keep it in the gist?

Well, this post read my mind. Literally my first thought waking up this morning was "why don't I have some way to use my .vimrc over ssh?" I open up Hacker News and voila!

Very nice - clean and simple.

I was thinking of putting together a crude hack to implement just a subset of what this offers. I cannot thank the authors enough. I'm trying this out the moment I get home.

I feel as though we should have had first-class support for portable environments all along, and it shocks me that we haven't considered building this kind of facility before. This could be a game changer. Like vim package managers and other sensibly modern things, I totally expect to see this evolve to become the new norm.

I see this kind of configuration:

* global personal configs (lightweight, truly global settings for work and home)

* local overrides (work, home, per machine, non-SSH)

* remote overrides (SSH machines)

Global configs should be portable everywhere. For everything else, I see a system capable of merging several such configs and matching the current environmental and capability context.

Fantastic. Looks like a perfect complement to my Workspace[1] script, and way easier than having to git push/pull my dotfiles directory.

Thanks!

https://github.com/matadon/workspace

I find it interesting that you say that, because my first thought was that this would be a step down from git pulling my dotfiles. All you need is to have a simple script that goes ln -s .zshrc ../.zshrc in your .dotfiles repo and getting a new shell up and running is as simple as running git pull && .dotfiles/setup.sh.

I like the idea of this in theory if you have machines that are frequently touched/overwritten, though, if you just want to have a baseline of sanity on them automatically when you log in.

I do something like this manually. I set up an alias on my home that copies a locally stored environments file onto any server I ssh onto.

Pretty simple stuff to set up, but allows for some pretty powerful configuration

Yeah I do this as well. But since I sometimes have to share remote accounts, customizing the environment often devolves into dotfile edit wars over stuff like "set -o emacs".

Why not have your environment defined when you run something like the following in Bash:

    . clarkm.env

That way you can each effectively have your own .bashrc. You could also have the following in your clarkm.env:

    unlink .emacs
    ln -s .emacs.clarkm .emacs

Or, if emacs supports it, alias in whatever command line flag that emacs uses to read from a different config file. Eg

    alias emacs="emacs --config .emacs.clarkm

I don't use emacs personally so the above will be inaccurate, but that kind of thing might work for you.

I wonder if it would be able to make it work with mosh (http://mosh.mit.edu/), which would be awesome!

I haven't tried it yet, but I believe it would work with the `--ssh=` option.

If you look into this and figure it out, please submit a pull request giving a short description on the readme.

Eureka! This so simple to use and so useful -- I'll use sshrc every day now. And the embedded xxd -ps is a clever copy. Great idea Russell. Thank you.

As a complement to this nice tool, I can recommend sshfs [1], which enables you to mount a remote machine as a local folder.

[1] https://www.digitalocean.com/community/tutorials/how-to-use-...

Love the elegant simplicity. Should we add something like this to Userify (https://userify.com) or perhaps offer to pull your dotfiles (.bashrc, .vimrc, etc) from Github?

What would it take to adapt this to also source other config files ? I'm thinking about gitconfig and vimrc, but I'm sure there could be more.

I use vcsh [1] for all my config files on multiple servers, but normally for just my own account.

In the exact use case here, I would likely just store a bash script named .bash_ansible or similar on the target server and just source that manually at login, but the sshrc system looks like an easier way to maintain a config without leaving a footprint.

[1] https://github.com/RichiH/vcsh

There's an example of using sehrc with vimrc and other dotfiles at the end of the readme.

"make your ssh sessions feel like 127.0.0.1"

"There's no place like ::1", just doesn't have the same ring to it, does it? :/

I wanted this 10 years ago, thank you!

np. The funny thing is that sshrc is just a bash script, so it really could have come about 10 years ago. All it took was a few weeks of unemployment and refusal to believe that it couldn't be done. For those of you that opt out of reading the source but are curious as to how it works internally: the tool zips all your files, dumps them as hex code, and stuffs them into an argument string for the little known ssh -t option, which carries instructions to undo the whole process on the server side. As a side note, stuffing a linux filesystem into an argument string is the reason why your ~/.sshrc.d can be much bigger than a megabyte - bash doesn't like processing commands that are that long.

Couldn't the 1MB limit be bypassed by invoking scp to transfer the files?

yes, but using a separate scp command requires a second round trip and second password/key authentication, which would double the wait time of the already slow ssh login process.

Interesting, I wonder if python fabric or its ssh libs could help.

not, if you configure multiplexing (and why wouldn't you) https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing

As an inferior option for older OpenSSH versions, you could also forward a port and send the tarball over that.

If people regularly send large directories, you might also want to extend this with rsync.

the little known ssh -t option is not documented to take an argument, i'm not sure this works the way you think it does.

But ssh -t forces pseudo-tty allocation and doesn't take arguments, what you are doing is appending command strings to the ssh command line.

you're right, this is a better way of thinking about it.

Are there any security implications using this? It sounds very handy if not.

It's constructed entirely from builtin unix commands, so it's solid. The biggest risk is that someone could put malicious code into your ~/.sshrc, which would be run on the server. However, if they have write access to your $HOME directory, you're already in big trouble, as they could just as easily add something like `alias ssh='ssh "rm -rf $HOME"' to your ~/.bashrc.

It doesn't let me change the prompt colours.

Is it possible to source my dotfiles?

Something like this:

# .sshrc

source ~/.bashrc

source ~/.alias

this is pretty awesome! any hint on how to load the vimrc config by default without the actual :so?

How is this any different than .bashrc or .bash_profile?

the .bashrc/.profile is synced automatically to each new box.

Do you like configuring bash{rc,_profile} on all the machines you connect to? Or would you prefer that the remote server used your local configs?

Well, I work on a number of different Unix servers that it make more sense to me to configure bash{rc,_profile} for each server I'm on.

I've seen tool after tool that tries to make SSH'ing into a remote machine more "comfortable", but I honestly don't do enough remote work over SSH to make it worth the time required to set it up. I probably spend an hour or two over SSH per week, and Ubuntu's minimalist shell defaults are perfectly fine for the little work I do.

There are plenty of people that do use ssh for the bulk of their work. In that scenario, these sorts of optimizations are quite useful.

Reply on news.ycombinator.com