Hacker News new | past | comments | ask | show | jobs | submit login

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.



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.


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.


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.


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.


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




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: