Hacker News Reader

Comment by jfb | Hacker News Reader

The single most useful thing about ssh to me is that it connects stdout/in across the channel (this is behavior inherited from rsh). This allows for e.g.:

  % (cd /foo; tar cpf - .) | ssh bar \(cd /baz\; tar xpf -\)

Or:

  % cat ~/.ssh/id_rsa.pub | ssh bar tee -a .ssh/authorized_keys

View on HN

This is a bit of a pet peeve of mine, but cd/tar should likely be joined with && - in other words, in what directory do you want tar to (not) run if cd fails? So consider:

    % (cd /foo && tar cpf - .) | ssh bar '(cd /baz && tar xpf -)'

or explore something like:

    % rsync -aSHx --update --delete -e ssh /foo/ user@bar:baz/.

GNU tar has evolved and can use simpler syntax: % tar cp -C /foo . | ssh bar tar xp -C /baz

It would be an interesting project to look at people's shell usage and try to determine when they started using Unix. I have loads of Irixisms that have only recently been crowded out of my head by Darwin BSDism.

Forgive my ignorance, but I don't know what what it means to connect "across the channel", but it sounds important. Do you know a link that explains the concept? I've failed to Google it.

It means that whatever you put into the ssh process's STDIN gets sent to the STDIN of the remote process. For example you can do this:

    tar cj $bigdir | ssh host 'tar xj'

That creates a tar.bz2 archive on your machine, sends it over ssh to the remote host, where it's unpacked. Ad hoc compressed and encrypted file transfers made easy.

That's a good illustration, but rsync, if available, would generally be preferred for that use case:

  rsync -az $bigdir host:$bigdir

Sure, of course. But I've used that tar|ssh combination so much that it was the first example of using the rsh-like stdout/in pairing that came to mind. As much as I bitch about Unix and POSIX and horrific shell brain damage, I still reach for crazy shell pipelines when I have data manipulation tasks up to some pretty large scale n.

What you pipe into ssh gets out of ssh on the host you're connected to.

So basically, you get :

      (local)            (remote)
    stdin -> ssh       ssh -> stdout

Hope that helps.

He's talking about forwarding stdin and stdout across the SSH connection to the program that SSH is running on the other end; such that the stdin of ssh is passed unmodified to the program and vice-versa.

Are you familiar with stdin/stdout/stderr on Unix and how they interact? What ssh does that I find so powerful is ensure that what you put into stdout on one side of a pipe flows out of stdin on the process that ssh starts on the remote host.

Of course, ssh also gives you the output of the remote process, so you can put an ssh command in the middle of a pipeline. My day to day life no longer involves interacting with lots of remote Unix systems, but when it did, it was really, really useful.

ssh-copy-id is made for exactly this:

  ssh-copy-id  -  install  your  public  key in a remote machine’s authorized_keys

the tip does work on OS X though, which doesn't have ssh-copy-id (by default, at least)

Reply on news.ycombinator.com