Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

stdout on one CentOS server needs to be piped to stdin on another CentOS server. Is this possible?


ScottPack, MikeyB and jofel all have valid answers. I awarded the answer to Scott because, even though my question didn't specify security as a requirement, it's always nice to be safe. However, the other two fellows' suggestions will also work.

share|improve this question
It's worth noting that the (only) major advantage of the non-ssh approach is throughput speed; if you're on a fast network and security is unnecessary this may be worth the extra inconvenience of typing two commands into two windows. – Random832 Mar 16 '12 at 12:53
up vote 56 down vote accepted

This is an unabashed yes. When one uses ssh to execute a command on a remote server it performs some kind of fancy internal input/output redirection. In fact, I find this to be one of the subtly nicer features of OpenSSH. Specifically, if you use ssh to execute an arbitrary command on a remote system, then ssh will map STDIN and sTDOUT to that of the command being executed.

For the purposes of an example, let's assume you want to create a backup tarball, but don't want to, or can't, store it locally. Let's have a gander at this syntax:

tar -cf - /path/to/backup/dir | ssh remotehost "cat - > backupfile.tar"

We're creating a tarball, and writing it to STDOUT, normal stuff. Since we're using ssh to execute a remote command, STDIN gets mapped to the STDIN of cat. Which we then redirect to a file.

share|improve this answer
That isn't any sort of "fancy internal input/output redirection" - just the plain, boring regular stuff. ssh reads from STDIN, just like any other tool, and passes it to the remote process. :) – Daniel Pittman Mar 15 '12 at 20:06
@DanielPittman: But it's just so much more fun to call it "fancy internal" garbage. – Scott Pack Mar 15 '12 at 20:07
Similarly, netcat on both ends makes for a great simple, easy communication channel. tar cf - /path/to/dir | nc 5000 on one server, nc -l -p 5000 > backupfile.tar on the other. – MikeyB Mar 15 '12 at 20:14
@MikeyB: You people what with your flying and your pants seats! – Scott Pack Mar 15 '12 at 20:49
@SamuelEdwinWard: Depends on your infrastructure and where the bottleneck is. A few days ago I was backing up about 14GB of data across a 1Gbps link. Even with two fast machines, enabling compression was 5 times slower. Without compression it was IO bound, with compression it was CPU bound. – Scott Pack Mar 16 '12 at 18:57

A convenient way of piping data between hosts when you don't need to worry about security over the wire is using netcat on both ends on the connection.

This also lets you set them up asynchronously:

On the "receiver" (really, you'll have two-way communication, but it's easier to think of it like this), run:

nc -l -p 5000 > /path/to/backupfile.tar

And on the "sender", run:

tar cf - /path/to/dir | nc 5000
share|improve this answer
Very good to know. This is good if the physical connection is trusted like perhaps a backup network or if the connection is already tunneled. – Wesley Mar 15 '12 at 21:39
Or if the data is something that's public anyway. – Samuel Edwin Ward Mar 15 '12 at 22:24
+1 netcat is an invaluable tool, especially when you don't have a ssh server running. – kwarrick Mar 15 '12 at 23:31

A very powerful tool for creating uni- and bidirectional connections is socat. For a short look at the possibilities, look at the examples in its manpage.

It replaces netcat and similar tools completely and has support for ssl encrypted connections. For beginners, it might be not simple enough, but it is at least good to know that it exists.

share|improve this answer
Excellent to know! – Wesley Mar 15 '12 at 23:08
+1 Good addition to the list and well said. – kwarrick Mar 15 '12 at 23:31
@WesleyDavid: To your "Update": Just for completeness, I've added to my answer that socat has SSL support, so encryption is with socat possible, too. However, ssh is in most cases the better and easier solution, so I would have chosen ScottPack's answer,too. – jofel Mar 15 '12 at 23:46

I find this to be the easiest, after setting up no password handshaking between servers for the user you are running the command as:


tar cf - . | ssh servername "cd /path-to-dir; tar xf -"

Compression on the fly

tar czf - . | ssh servername "cd /path-to-dir; tar xzf -"
share|improve this answer
Using compression on the tar file is a very bad idea if your ssh is already configured for compression. – Anthon Feb 19 '14 at 19:10

Try to put your ssh public key in another host just by one command

ssh root@example.com 'cat >> .ssh/authorized_keys' < .ssh/id_rsa.pub
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.