3 ms·

I wanted this 10 years ago, thank you!

• Russell91 12y ago
  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.
  • beerbajay 12y ago
    Couldn't the 1MB limit be bypassed by invoking scp to transfer the files?
    • Russell91 12y ago
      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.
      • mixmastamyk 12y ago
        Interesting, I wonder if python fabric or its ssh libs could help.
      • dnet 12y ago
        not, if you configure multiplexing (and why wouldn't you) https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Multiplexing
        • JoachimSchipper 12y ago
          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.
  • ta0967 12y ago
    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.
  • equoid 12y ago
    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.
    • Russell91 12y ago
      you're right, this is a better way of thinking about it.